模块化打包
随着前端代码量的膨胀，插件日益增多，我们不得不花大量时间去管理。模块化就是管理代码最主流的方式。它把我们的代码根据功能不同，划分成不同模块，来单独维护，从而达到便于管理的目的，提高开发效率，降低维护成本。
模块化演变
既然模块化的出现是因为早期设计对代码量的预估不足，是一种对于补足方式，那它肯定是一点点演变到如今的形式。
首先，在最开始出现的是文件划分式。
也就是把一个功能的代码放在一个文件夹之下，如下图 7.1 。
内部的每个文件就是一个独立模块，在哪使用在引入。但是因为模块内的命名也好还是函数也好，都是公用的。可以直接对其进行更改，污染全局作用域。而且文件多了之后，极可能出现名称冲突的问题。而且模块之前的依赖关系只能去代码里找（一般也不会找，什么时候报错什么时候发现问题），复用、移植很麻烦，如图 7.2。
下一个阶段就是，通过命名空间进行模块化。
命名空间方式指的是，我们把模块内的成员从全局挂载到模块下。让每个模块成为一个全局对象，如图 7.3。这样就可以避免全局污染问题。
再后来就是通过立即执行函数来为模块提供私有空间，以保护模块内的成员不会在模块外被更改。
模块内部的成员再根据需求挂载到全局上，从而达到成员私有化的目的。而且这个阶段的模块被函数包裹在内，他需要什么一目了然（我们可以根据函数的入参判断）如图 7.4。
目前来说，我们对于模块化的处理方式已经比较统一
在 node 环境中，我们采用 commonJS 去组织模块（ requires ）。 在浏览器环境中，使用 ES Moudle 的规范。
模块化规范
node 环境中使用 requires 大家想必都不陌生，这里就不多赘述。那下面我们就着重来介绍一下这个 ES Moudle 。
因为现在很多浏览器已经开始支持 ES Moudle ，所以当我们在使用的时候，只需要写上 type=moudle 即可。
首先梳理一下 他的特性。
1.在 ES Moudle 中会自动使用严格模式。
2.每个 ES Moudle 都运行在私有作用域中。
3.ES Moudle 模块是通过 CORS 方式请求外部 JS 模块的。
4.ES Moudle 中的代码会自动延迟执行（相当于 defer 属性，即渲染之后）。
基于以上特性，我们来了解一下 ESM 的使用。
首先就是导出和导入， export 和 import 。用法如图 7.5
在实际开发中，我们经常会把一个模块的内容写在一个对象或者类中，然后直接通过 export defult 导出，那这个时候我们在引用的时候可以为他随便命名。如下图 7.6
注意 敲黑板！！！
这里 export 和 import 的 {} 不是 ES6 的字面量对象，而是固定格式。不要有 export 123 这样骚操作。导出的是引用，是地址，不是深拷贝，要考的！import 引用的对象是只读的，不能改，会报错！想要动态导入可以使用 import（），它是一个promise，在.then 里进行后续操作。
常用模块化工具
首先我们来介绍一下现在最常用的 webpack 的使用。
先介绍一下它的工作原理，就是从入口文件（一般是 JS 文件）处理，有引用就引用加进来。如下图 7.8
概念很笼统，一看就会，一学就废。
因为我最开始学 webpack 的时候，上网一搜直接就是大段配置，看的头皮发麻。再加上刚参加工作，底子不好，学的一头雾水。所以我们先从最基础的配置开始。
创建文件 code webpack.config.js 。内容如下图 7.9。
导出的对象就是它的核心，第一个属性，mode，属性有生产和开发，他们开启的优化项不同，可按需选取。再往后两个 ，入口出口，清晰明了。publicPath 可以理解为提前指定的、网站第一级目录（避免打包图片时找不到打包后的位置）。
这样最基本的配置就有了！
由于 webpack 最基础的功能是给 js 文件进行打包。所以其他的 css、png 之类的需要添加资源处理模块。故而引出了下一个属性 module 。如下图 7.10。
module 里最常用的属性就是 rules 。其中描述了对 js 之外其他类型文件的处理。它是一个数组，每个元素是个对象 ，常用两个属性 test 正则匹配规则， use 引用的 loader 。loader 就是处理这些文件的模块。要提前安装 yarn add。
loader 很多，比如处理图片时可以用 file-loader 进行物理复制，也可以使用 url-loader loader 去进行转码，大家可以去看看文档来选择符合要求的loader，多试试，刚开始还是很有意思的。
这些 loader 大概可以分三类，编译转换类（把文件转换成 js 代码），文件操作类（拷贝文件，导出拷贝之后的路径 如 file-loader ），代码检查类（对代码进行校验，统一风格提高质量）
loader 这个东西看起来很抽象，其实就是一个管道，根据输入然后处理格式，按照规范（js 文件格式）返回。如图 7.11
其实上边配置就可以满足所有打包需求了，但是因为程序为了方便嘛，所以我们需要自动化，所以就有了配置的另一个核心 plugin 。
如删除上一次打包内容，压缩代码，拷贝不需要处理的文件等。
先上 plugin 的使用，先安装想要的插件，例子中用了一个清除上次打包内容的插件，clean-webpack-plugin ，安装过后，我们先引入，然后在 plugins 中写入，plugins 是个数组，每个元素都是一个实例。 如下图 7.12.
上图同时演示了生成 html 文件的插件，引入方式略有不同，要看文档里怎么写的。实例时传入一个对象，根据属性修改生成页面的参数，也可以传入模板。
一起就绪，开开心心的去开发，然后问题出现了，我改一次代码就得打包一次，很麻烦，也不同步。 所以我们需要 webpack-dev-server 。然后以命令启动项目实现同步刷新。试了一下发现果然可以同步更新页面，但是静态文件没有。所以就需要去 code webpack.config.js 中配置。如下图 7.13
原因是 webpack-dev-server 并不会对文件进行打包生成 dist 文件夹，所以找不到静态文件，给他一个指向就好了。
这个属性开可以解决代理 API 的问题。当访问你标注的 API 时就会，就会跳转到指定的 API 。如下图 7.14
ESLint
在多人开发时，规范是一个很重要的问题，方便阅读彼此代码，方便挑错修改。
一般在项目上为了解决这个问题，我们会选择 EsLint 来解决这个问题，它一方面监控 JS 编写的质量，可以提升初学者的编码水平。另一方面也可以统一开发者的编码风格。
安装 Eslint 后执行 yarn eslint 文件名，校验文件规范性，然后会提示你需要初始化一个配置文件，然后跟着命令一步步选择，得到你要的配置文件。
再执行 yarn eslint 文件名，就可以看到你不符合规范的地方，如下图 7.15.
我们可以看到目录里生成了一个 eslint 的配置文件，我们一般不需要修改其中内容，但是如果有特殊要求，就必须要修改了。我们来理解一下这里边的配置文件。
Eslint 没问题 webpack 也没问题，但是这应该是一次执行下来，而不是输入两行命令，所以我们需要把两者结合起来。方法也很简单，安装 eslint-loader 写在 webpack 配置的 rules 里。如下图 7.18。
ps: 最后说一下问什么每次安装都要在开发环境下，因为首先我们安装的这些东西，是为了项目运行。没必要全局安装。其次，项目多人开发，拷贝的时候不需要再考虑安装依赖的问题。
