每篇文章纯属个人经验观点，如有错误疏漏欢迎指正。转载请附带作者信息及出处。 点这里查看 webpack 系列文章目录 博客中的代码位于 码云Git仓库，如有需要可自行前往下载。
webpack 默认就会对 js 资源进行处理，我们这里只需要对其进行压缩等操作即可。
因为部分浏览器并不兼容 es6 语法，而我们在开发时经常会使用到各种新特性，所以就需要我们对各种特性进行兼容性处理，现在我们可以直接借助 webpack 来完成这项工作，主要有以下三种方式：
老规矩，先下包，这里需要使用 babel 的三个包：
npm i babel-loader @babel/preset-env @babel/core -D我们新建一个 JS 的文件，并利于 es6 语法写一些低版本浏览器不能兼容的内容：
// index.html const fn = () => { console.log("index.js"); } new Promise(resolve => { setTimeout(() => { resolve('hello') }, 2000) }).then(res => { console.log(res) })修改配置文件：
// webpack.config.js module: { rules: [ { test: /\.js$/, // 排除掉第三方库中的内容 exclude: /node_modules/, use: { loader: "babel-loader", options: { // 引用 babel/preset-env 来进行转换语法 presets: ['@babel/preset-env'] } } } ] },打包成功后，我们发现只有箭头函数进行了处理，而 Promise 并没有被转换：
这种方式只能装换简单的语法，比如说 let const 和箭头函数等等，当遇到 Promise 等相对复杂的语法时，并没有对其进行转换。
如果想要兼容所有的 es6 语法，需要借助 @babel/polyfill：
npm i @babel/polyfill -D要注意这个包并不是 babel 的插件，不需要修改配置文件，而是在需要它的地方直接引入：
// index.js import '@babel/polyfill'; // 省略 ...引入之后无须修改配置即可直接打包，我们可以在 IE 浏览器中查看打包后的效果。
当我们打开打包生成的文件时，发现文件变的非常大，并且其中出现了很多我们并没有用到的代码，代码冗余现象严重，我们对比一下两次打包的结果：
为了解决兼容全部语法造成文件体积过大，代码冗余的问题，这里就需要通过 CoreJs 来实现按需加载：
npm i core-js -D修改配置文件，为 polyfill 添加限制：
rules: [ { test: /\.js$/, exclude: /node_modules/, use: { loader: "babel-loader", options: { // 设置 babel 通过那些规定做兼容性处理 presets: [ [ '@babel/preset-env', { // useBuiltIns 共有三个值： // false: 不对 polyfill 做操作 // entry: 根据配置的浏览器兼容版本，引入浏览器不兼容的 polyfill // usage: 根据配置的浏览器兼容版本，以及代码中使用到的语法来 决定引入那些 polyfill useBuiltIns: 'usage', // 指定使用那个版本的 corejs 进行转换 corejs: { version: 3.6 }, // 配置浏览器需要兼容的版本 key 为浏览器名称， value 为浏览器的版本号 targets: { // 截至到现在 chrome 现在已经更新到 86 版本了 chrome: "70", ie: "9" } } ] ] } } } ]这时候我们在打包后就发现，生成的文件大小已经大大缩减了：
目前大部分的项目都要求兼容到 IE8 以上了，如果还需要兼容 IE8，那不仅需要补充 es6 还需要补充 es5 的部分 API，所以还需要借助 @babel/runtime ；然后配置 optimization 中的 UglifyJsPlugin 来处理 ES3 中的关键字等等。。。有需要的同学可以自行百度。
ESLint 是一个插件化的代码检测工具，其作用主要有以下几点：
统一代码风格规则，如：缩进用几个空格；是否用驼峰命名法来命名变量和函数名等；减少错误， 如：相等比较必须用 ===，变量在使用前必须被声明，在条件语句中不能使用赋值语句等；提高代码质量，如：函数最多有多少条件分支；最多有几个参数，代码块最多能嵌套多少层等；其他。如： 禁用 alert ，提高用户体验等等；使用 ESlint 进行代码检查可以对项目的质量进行很大的提升，尤其是在团队开发时，可以明确规范开发者的代码风格，保持项目成员代码风格的一致性，在团队协作方面，这比其他所有作用都重要。
但由于 ESlint 具有超强的检测性，往往刚刚接触的同学面对满屏的红线都会忍不住抓狂，但除非你一直选择自己闭门造车，不参与团队开发，否则早晚要接触 ESlint 和 TypeScript 。同时也有简单的办法，我们可以借助插件来自动修复代码，比如 vscode 的 autofix；
要使用 eslint 需要安装一下几个库：
npm i eslint eslint-loader eslint-config-airbnb-base eslint-plugin-import -D其中 airbnb-base 是检测的规则，如果想使用其它规则，需要安装其它的库并在 package.json 中进行相应修改：
// package.json // 设置 eslint 规则 "eslintConfig": { // 继承 airbnb-base 的检测规则 "extends": "airbnb-base" }修改 webpack 配置文件：
// 省略... module: { rules:[ { test: /\.js$/, // 排查第三方库，第三方库无需检查格式 exclude: /node_modules/, use: { // 使用 eslint-loader 进行检查 loader: "eslint-loader" } } ] },修改完成后，我们故意将 index.js 中的代码格式改的乱一点，尝试将代码进行打包：
毫无疑问打包失败了，ESlint 告诉我们 index.js 构建失败，在 index.js 的第一行中，换行符出现问题，具体的规则可以搜索 linebreak-style 来查看，第二行说这个文件开头位置不能有太多的空行等等。。
由于出现的错误太多，手动修复肯定是不现实的，因为这样实在是太麻烦了，所以我们可以通过配置项，达到自动修复的目的：
use: { // 使用 eslint-loader 进行检查 loader: "eslint-loader", options: { // 自动修复 fix: true } }启用自动修复十分简单，只需要在配置项中添加 fix:true 即可，然后我们再次执行打包命令：
这时候我们发现错误减少了很多，但依然存在两种错误：
error ：声明了变量 fn 但是并没有使用过这个变量；warnging：意料之外的表达式 console；我们重新打开 index.js 文件，发现代码的格式变的十分整齐，但是内容并没有发生改变。这是因为上述的错误属于编程错误，而不是语法错误， eslint 只是帮我们修改了代码的格式，但并不会帮我们修改代码，所以这种类型的错误需要我们进行手动更改。
除了手动修改外，我们可以通过注释使 eslint 忽略相关错误：
// index.js // 通过注释使 eslint 忽略错误可以 // eslint-disable-next-line const fn = () => { console.log('index.js'); };重新打包：
另外我们可以对编辑器进行相应配置，让我们在保存代码的时候通过 eslint 的规则对代码进行自动修复，具体如何配置，可以百度：vsCode 配置 Eslint 自动修复。
感谢大家的观看，点赞和收藏，我们下篇博客再见。
每篇文章纯属个人经验观点，如有错误疏漏欢迎指正。 转载请附带作者信息及出处。您的评论和关注是我更新的动力!
下面是我的个人微信公众号，我会在里面定期更新前端的相关技术文章，欢迎大家前来讨论学习。如果有什么问题需要老王帮忙或者想看关于某个主题的文章，也可以通过留言等方式来联系老王。 都看到这里了，三连一下呗~~~。点个收藏，少个 Bug 。
