webpack的用途和本质
webpack本质上是一个现代js应用程序的静态模块打包器。当webpack处理应用程序时,它会递归的构建一个依赖关系图,其中包含应用程序需要的每个模块,然后将这些模块打包成一个或多个bundle。
其实就是把所有的非 js 资源都转换成 js (如把一个 css 文件转换成“创建一个 style
标签并把它插入 document
”的脚本、把图片转换成一个图片地址的 js 变量或 base64 编码等),然后用 CommonJS 的机制管理起来。
webpack是通过js来获取和操作其他文件资源的,比如webpack想处理less,但是它并不会直接从本地的文件夹中直接通过路径去读取css文件,而且通过执行入口js文件,如果入口文件中,或者入口文件相关联的js文件中含有 require(xx.less) 这个less文件,那么它就会通过对应的loader去处理这个less文件
webpack的核心思想
-
一切皆模块: 正如js文件可以是一个“模块(module)”一样,其他的(如css、image或html)文件也可视作模 块。因此,你可以require(‘myJSfile.js’)亦可以require(‘myCSSfile.css’)。这意味着我们可以将事物(业务)分割成更小的易于管理的片段,从而达到重复利用等的目的。
-
按需加载: 传统的模块打包工具(module bundlers)最终将所有的模块编译生成一个庞大的bundle.js文件。但是在真实的app里边,“bundle.js”文件可能有10M到15M之大可能会导致应用一直处于加载中状态。因此Webpack使用许多特性来分割代码然后生成多个“bundle”文件,而且异步加载部分代码以实现按需加载。
webpack构建流程
从启动webpack构建到输出结果经历了一系列过程,它们是:
-
解析webpack配置参数,合并从shell传入和
webpack.config.js
文件里配置的参数,生产最后的配置结果。 -
注册所有配置的插件,好让插件监听webpack构建生命周期的事件节点,以做出对应的反应。
-
从配置的
entry
入口文件开始解析文件构建AST语法树,找出每个文件所依赖的文件,递归下去。 -
在解析文件递归的过程中根据文件类型和loader配置找出合适的loader用来对文件进行转换。
-
递归完后得到每个文件的最终结果,根据
entry
配置生成代码块chunk
。 -
输出所有
chunk
到文件系统。
需要注意的是,在构建生命周期中有一系列插件在合适的时机做了合适的事情,比如UglifyJsPlugin
会在loader转换递归完后对结果再使用UglifyJs
压缩覆盖之前的结果。
webpack是如何进行资源的打包
-
每个文件都是一个资源,可以用require/import导入js
-
每个入口文件会把自己所依赖(即require)的资源全部打包在一起,一个资源多次引用的话,只会打包一份
-
对于多个入口的情况,其实就是分别独立的执行单个入口情况,每个入口文件不相干(可用CommonsChunkPlugin优化)
webpack的打包原理
-
bundle.js是以模块 id 为记号,通过函数把各个文件依赖封装达到分割效果,如 id 为 0 表示 entry 模块需要的依赖, 1 表示 util1模块需要的依赖
-
require资源文件 id 表示该文件需要加载的各个模块。
例子:整个应用的入口为 entry.js,entry.js引用 util1.js util2.js, 同时util1.js又引用了util2.js
关键问题是: 它打包的会不会将 util2.js打包两份?
其实不会的,webpack打包的原理为,在入口文件中,对每个require资源文件进行配置一个id, 也就是说,对于同一个资源,就算是require多次的话,它的id也是一样的,所以无论在多少个文件中require,它都只会打包一份
-
entry.js 入口文件对应的id为 1
-
util1.js的id为 2
-
util2.js的id为 3
entry.js引用了 2 和 3, util1.js引用了 3,说明了entry和util1引用的是同一份,util2.js不会重复打包
css单文件入口的情况
上面分析了js的情况,其实css也是一个道理。它同样也会为每个css资源分配一个id, 每个资源同样也只会导入一次。
参考博客:http://www.ruanyifeng.com/blog/2014/09/package-management.html