在实际开发中,我们通常会在构建工具中通过配置babel来对其进行使用的,比如在webpack中。
那么就需要去安装相关的依赖。
1)安装@babel/core 和 babel-loader
npm i -D @babel/core babel-loader
2)在webpack.config.js中配置
module.exports = {
module: {
rules: [
{
test: /\.m?js$/, //m表示0次或1次
use: {
loader: 'babel-loader'
}
}
]
}
}
可是,打包后还是原先的ES6代码。我们在使用babel的时候,必须指定插件才会生效(同postcss)
3)指定插件
缺点:但是,如果要让我们一个个地去安装使用插件,那么需要手动管理大量的babel插件。
解决方案:我们可以直接给webpack提供一个preset,webpack就会根据我们的预设来加载对应的插件列表,并将其传递给babel。
4)设置preset
① 安装preset-env
npm i -D @babel/preset-env
②在webpack.config.js中配置
③ 运行 npm run build,看结果
5)设置目标浏览器 browerslist
我们最终打包的javascript代码,是需要跑在目标浏览器上的,那么如何告知babel我们的目标浏览器呢?
- browerslist工具,之前在postcss中已经配置过了;
- target属性
target的优先级高于browserslist,也就是说,当设置target后,browserlist的配置会失效。但我们开发中推荐在browserlist里配置,这样能和postcss同步。
6)Stage-X的preset
要了解Stage-X,我们需要先了解一下TC39的组织:
- TC39是指技术委员会(Technical Committee)第 39 号;
- 它是 ECMA 的一部分,ECMA 是 “ECMAScript” 规范下的 JavaScript 语言标准化的机构;
- ECMAScript 规范定义了 JavaScript 如何一步一步的进化、发展;
TC39 遵循的原则是:分阶段加入不同的语言特性,新流程涉及四个不同的 Stage:
- Stage 0:strawman(稻草人),任何尚未提交作为正式提案的讨论、想法变更或者补充都被认为是第 0 阶段的”稻草人”;
- Stage 1:proposal(提议),提案已经被正式化,并期望解决此问题,还需要观察与其他提案的相互影响;
- Stage 2:draft(草稿),Stage 2 的提案应提供规范初稿、草稿。此时,语言的实现者开始观察 runtime 的具体实现是否合理;
- Stage 3:candidate(候补),Stage 3 提案是建议的候选提案。在这个高级阶段,规范的编辑人员和评审人员必须在最终规范上签字。Stage 3 的提案不会有太大的改变,在对外发布之前只是修正一些问题;
Stage 4:finished(完成),进入 Stage 4 的提案将包含在 ECMAScript 的下一个修订版中
① Babel的Stage-X设置
在babel7之前(比如babel6中),我们会经常看到这种设置方式:
它表达的含义是使用对应的 babel-preset-stage-x 预设
- 但是从babel7开始,已经不建议使用了,建议使用preset-env来设置;
7)babel的配置文件
像之前一样,我们可以将babel的配置信息放到一个独立的文件中,babel给我们提供了两种配置文件的编写:
- babel.config.json(或者.js,.cjs,.mjs)文件;
- .babelrc.json(或者.babelrc,.js,.cjs,.mjs)文件;
它们两个有什么区别呢?目前很多的项目都采用了多包管理的方式(babel本身、element-plus、umi等);
- .babelrc.json:早期使用较多的配置方式,但是对于配置Monorepos项目是比较麻烦的;
- babel.config.json(babel7):可以直接作用于Monorepos项目的子包,更加推荐;
在项目根目录新建babel.config.js文件:
module.exports = {
presets: [
['@babel/preset-env']
]
}
然后移除webpack.config.js的babel配置:
module.exports = {
module: {
rules: [
{
test: /\.m?js$/,
use: {
loader: 'babel-loader',
}
}
]
}
}
8)polyfill
9)TypeScript