webpack打包原理(webpack打包原理优化)

今天药忘吃喽~ 2023-09-26 14:37 9阅读 0赞

## fis打包和webpack打包的区别 ##

定位不同，webpack定位是一个打包工具，模块化。其实自动化的工具更好用gulp之类解决。fis3直接定位为一个全功能工具，官方文档介绍中：解决性能优化，模块化，自动化，甚至包括代码规范，部署等问题。个人喜欢用webpack，可以更灵活的搭配其它工具使用，且生态系统强大，当然最近比较火的可能是rollup，它打包的文件体积更小。fis/fis3是grunt、gulp之后兴起的一个比较优秀的前端工程解决方案。它的本质是基于静态资源标记+动态解析静态资源表，在模板、js里边使用特殊的标记方法引用前端资源，构建的时候生成一张资源依赖表，浏览器或者后端模板语言在解析的过程中通过查表得到某个静态资源在不同环境下的引用路径，所以不管是纯前端渲染(标记方法已经转换成浏览器能识别的了)还是后端(php、node、java)渲染，都很容易支持到，这样可以做到非常精细化的控制资源的按需加载。可以说fis真正做到了静态资源动态按需加载。

再来说说webpack，这货其实本质上是静态打包，生成chunk需要手动配置entry，虽然可以使用commonschunkplugin、dll等插件辅助提取公共代码，以及采用code split切割进行懒加载，但这个粒度十分难把握，配置起来也比较困难(fis是自动生成依赖关系和自动处理懒加载)。

单从原理上来讲，fis比webpack要先进好多好多。但是fis先进的理念也成为它的一个缺陷，就是自定义的一套标记语言，大量自定义的资源标记语法并不能被浏览器直接接解析或者被社区流行的工具(browserify/babel)转换，比如fis依赖自家定制的mod.js来解析\`require()\`函数(即定位资源)以及资源base64内嵌语法\`\_\_include()\`等。这一点直接导致了fis无法和后来的强大的npm社区对接，大量的npm前端模块在fis用不了，笔者认为这是导致各公司在选择前端统一的构建工具标准时不考虑fis的最大原因吧。

fis的作者

曾经说过，webpack只差一步——生成支持静态资源表，就完美了，深以为然！目前，webpack好像有生成sourcemap的插件，但是缺少配套的解析sourcemap的工具，后端的模板引擎貌似也没有支持sourcemap。

webpack现有的懒加载手段不完美，但是基本够用，主要是它直接支持commonjs规范的require语法，再配置babel等还可以直接解析es6语法(当然，fis也可以通过插件支持es6的)，加上可以直接使用npm模块这一点，依托npm社区强大红利来搭建公司级公共组件化规范。所以综合考虑，webpack目前是前端构建工具的首选。

我们公司前端内部，也在试图搭建基于webpack+npm的前端模块化生态。

![webpack打包原理][webpack]

## webpack执行机制流程是怎么样的 ##

几乎所有业务的开发构建都会用到 webpack 。的确，作为模块加载和打包神器，只需配置几个文件，加载各种 loader 就可以享受无痛流程化开发。但对于 webpack 这样一个复杂度较高的插件集合，它的整体流程及思想对我们来说还是很透明的。那么接下来我会带你了解 webpack 这样一个构建黑盒，首先来谈谈它的流程。

1. webstorm 中配置 webpack-webstorm-debugger-script

在开始了解之前，必须要能对 webpack 整个流程进行 debug ，配置过程比较简单。

先将 webpack-webstorm-debugger-script 中的软件外包企业公司?webstorm-debugger.js 置于 webpack.config.js 的同一目录下，搭建好你的脚手架后就可以直接 Debug 这个 webstorm-debugger.js 文件了。

2. webpack.config.js 配置

估计大家对 webpack.config.js 的配置也尝试过不少次了，这里就大致对这个配置文件进行个分析。

var path = require('path');

var node\_modules = path.resolve(\_\_dirname, 'node\_modules');

var pathToReact = path.resolve(node\_modules, 'react/dist/react.min.js');

module.exports = \{

// 入口文件，是模块构建的起点，同时每一个入口文件对应最后生成的一个 chunk。

entry: \{

bundle: \[

'webpack/hot/dev-server',

'webpack-dev-server/client?:8080',

path.resolve(\_\_dirname, 'app/app.js')

// 文件路径指向(可加快打包过程)。

resolve: \{

alias: \{

'react': pathToReact

// 生成文件，是模块构建的终点，包括输出文件与输出路径。

output: \{

path: path.resolve(\_\_dirname, 'build'),

filename: '\[name\].js',

// 这里配置了处理各模块的 loader ，包括 css 预处理 loader ，es6 编译 loader，图片处理 loader。

module: \{

loaders: \[

test: /\\.js$/,

loader: 'babel',

query: \{

presets: \['es2015', 'react'\]

noParse: \[pathToReact\]

// webpack 各插件对象，在 webpack 的事件流中执行对应的方法。

plugins: \[

new webpack.HotModuleReplacementPlugin();

除此之外再大致介绍下 webpack 的一些核心概念:

loader : 能转换各类资源，并处理成对应模块的加载器。loader 间可以串行使用。

chunk : code splitting后的产物，也就是按需加载的分块，装载了不同的module。

对于module和chunk的关系可以参照webpack官方的这张图:

plugin : webpack 的插件实体，这里以 UglifyJsPlugin 为例。

function UglifyJsPlugin(options) \{

this.options = options;

module.exports = UglifyJsPlugin;

UglifyJsPlugin.prototype.apply = function(compiler) \{

compiler.plugin("compilation", function(compilation) \{

compilation.plugin("build-module", function(module) \{

compilation.plugin("optimize-chunk-assets", function(chunks, callback) \{

// Uglify 逻辑

compilation.plugin("normal-module-loader", function(context) \{

在 webpack 中你经常可以看到 compilation.plugin('xxx', callback) ，你可以把它当作是一个事件的绑定，这些事件在打包时由 webpack 来触发。

3. 流程总览

在具体流程学习前，可以先通过这幅 webpack整体流程图 了解一下大致流程(建议保存下来查看)。

shell 与 config 解析

每次在命令行输入 webpack 后，操作系统都会去调用 ./node\_modules/.bin/webpack 这个 shell 脚本。这个脚本会去调用./node\_modules/webpack/bin/webpack.js 并追加输入的参数，如 -p , -w 。(图中 webpack.js 是 webpack 的启动文件，而 $@ 是后缀参数)

在 webpack.js 这个文件中 webpack 通过 optimist 将用户配置的 webpack.config.js 和 shell 脚本传过来的参数整合成 options 对象传到了下一个流程的控制对象中。

1. optimist

和 commander 一样，optimist 实现了 node 命令行的解析，其 API 调用非常方便。

var optimist = require("optimist");

optimist

.boolean("json").alias("json", "j").describe("json")

.boolean("colors").alias("colors", "c").describe("colors")

.boolean("watch").alias("watch", "w").describe("watch")

获取到后缀参数后，optimist 分析参数并以键值对的形式把参数对象保存在 optimist.argv 中，来看看 argv 究竟有什么？

// webpack --hot -w

hot: true,

profile: false,

watch: true,

2. config 合并与插件加载

在加载插件之前，webpack 将 webpack.config.js 中的各个配置项拷贝到 options 对象中，并加载用户配置在 webpack.config.js 的 plugins 。接着 optimist.argv 会被传入到 ./node\_modules/webpack/bin/convert-argv.js 中，通过判断 argv 中参数的值决定是否去加载对应插件。(至于 webpack 插件运行机制，在之后的运行机制篇会提到)

ifBooleanArg("hot", function() \{

ensureArray(options, "plugins");

var HotModuleReplacementPlugin = require("../lib/HotModuleReplacementPlugin");

options.plugins.push(new HotModuleReplacementPlugin());

return options;

options 作为最后返回结果，包含了之后构建阶段所需的重要信息。

entry: \{\},//入口配置

output: \{\}, //输出配置

plugins: \[\], //插件集合(配置文件 + shell指令)

module: \{ loaders: \[ \[Object\] \] \}, //模块配置

context: //工程路径

这和 webpack.config.js 的配置非常相似，只是多了一些经 shell 传入的插件对象。插件对象一初始化完毕， options 也就传入到了下个流程中。

var webpack = require("../lib/webpack.js");

var compiler = webpack(options);

编译与构建流程

在加载配置文件和 shell 后缀参数申明的插件，并传入构建信息 options 对象后，开始整个 webpack 打包最漫长的一步。而这个时候，真正的 webpack 对象才刚被初始化，具体的初始化逻辑在 lib/webpack.js 中，如下:

function webpack(options) \{

var compiler = new Compiler();

...// 检查options,若watch字段为true,则开启watch线程

return compiler;

webpack 的实际入口是 Compiler 中的 run 方法，run 一旦执行后，就开始了编译和构建流程 ，其中有几个比较关键的 webpack 事件节点。

compile 开始编译

make 从入口点分析模块及其依赖的模块，创建这些模块对象

build-module 构建模块

after-compile 完成构建

seal 封装构建结果

emit 把各个chunk输出到结果文件

after-emit 完成输出

1. 核心对象 Compilation

compiler.run 后首先会触发 compile ，这一步会构建出 Compilation 对象:

compilation类图

这个对象有两个作用，一是负责组织整个打包过程，包含了每个构建环节及输出环节所对应的方法，可以从图中看到比较关键的步骤，如 addEntry() , \_addModuleChain() , buildModule() , seal() , createChunkAssets() (在每一个节点都会触发 webpack 事件去调用各插件)。二是该对象内部存放着所有 module ，chunk，生成的 asset 以及用来生成最后打包文件的 template 的信息。

2. 编译与构建主流程

在创建 module 之前，Compiler 会触发 make，并调用 Compilation.addEntry 方法，通过 options 对象的 entry 字段找到我们的入口js文件。之后，在 addEntry 中调用私有方法 \_addModuleChain ，这个方法主要做了两件事情。一是根据模块的类型获取对应的模块工厂并创建模块，二是构建模块。

而构建模块作为最耗时的一步，又可细化为三步:

调用各 loader 处理模块之间的依赖

webpack 提供的一个很大的便利就是能将所有资源都整合成模块，不仅仅是 js 文件。所以需要一些 loader ，比如 url-loader ，jsx-loader ， css-loader 等等来让我们可以直接在源文件中引用各类资源。webpack 调用 doBuild() ，对每一个 require() 用对应的 loader 进行加工，最后生成一个 js module。

Compilation.prototype.\_addModuleChain = function process(context, dependency, onModule, callback) \{

var start = this.profile && +new Date();

// 根据模块的类型获取对应的模块工厂并创建模块

var moduleFactory = this.dependencyFactories.get(dependency.constructor);

moduleFactory.create(context, dependency, function(err, module) \{

var result = this.addModule(module);

this.buildModule(module, function(err) \{

// 构建模块，添加依赖模块

\}.bind(this));

调用 acorn 解析经 loader 处理后的源文件生成抽象语法树 AST

Parser.prototype.parse = function parse(source, initialState) \{

var ast;

if(!ast) \{

// acorn以es6的语法进行解析

ast = acorn.parse(source, \{

ranges: true,

locations: true,

ecmaVersion: 6,

sourceType: "module"

遍历 AST，构建该模块所依赖的模块

对于当前模块，或许存在着多个依赖模块。当前模块会开辟一个依赖模块的数组，在遍历 AST 时，将 require() 中的模块通过addDependency() 添加到数组中。当前模块构建完成后，webpack 调用 processModuleDependencies 开始递归处理依赖的 module，接着就会重复之前的构建步骤。

Compilation.prototype.addModuleDependencies = function(module, dependencies, bail, cacheGroup, recursive, callback) \{

// 根据依赖数组(dependencies)创建依赖模块对象

var factories = \[\];

for(var i = 0; i < dependencies.length; i++) \{

var factory = \_this.dependencyFactories.get(dependencies\[i\]\[0\].constructor);

factories\[i\] = \[factory, dependencies\[i\]\];

// 与当前模块构建步骤相同

3. 构建细节

module 是 webpack 构建的核心实体，也是所有 module的 父类，它有几种不同子类：NormalModule , MultiModule ,ContextModule , DelegatedModule 等。但这些核心实体都是在构建中都会去调用对应方法，也就是 build() 。来看看其中具体做了什么:

// 初始化module信息，如context,id,chunks,dependencies等。

NormalModule.prototype.build = function build(options, compilation, resolver, fs, callback) \{

this.buildTimestamp = new Date().getTime(); // 构建计时

this.built = true;

return this.doBuild(options, compilation, resolver, fs, function(err) \{

// 指定模块引用，不经acorn解析

if(options.module && options.module.noParse) \{

if(Array.isArray(options.module.noParse)) \{

if(options.module.noParse.some(function(regExp) \{

return typeof regExp === "string" ?

this.request.indexOf(regExp) === 0 :

regExp.test(this.request);

\}, this)) return callback();

\} else if(typeof options.module.noParse === "string" ?

this.request.indexOf(options.module.noParse) === 0 :

options.module.noParse.test(this.request)) \{

return callback();

// 由acorn解析生成ast

try \{

this.parser.parse(this.\_source.source(), \{

current: this,

module: this,

compilation: compilation,

options: options

\} catch(e) \{

var source = this.\_source.source();

this.\_source = null;

return callback(new ModuleParseError(this, source, e));

return callback();

\}.bind(this));

对于每一个 module ，它都会有这样一个构建方法。当然，它还包括了从构建到输出的一系列的有关 module 生命周期的函数正如 lin瑞玉的回答 所说，webpack-dev-middle 把文件放在内存中了。实现过程大致为：webpack 有一个 outputFileSystem 选项，通过这个选项 webpack 在编译时可以使用自定义的 fs 替换 Node 原生 fs，只要 API 兼容。webpack-dev-middle 正是把它替换成

再看看别人怎么说的。

[webpack]: https://img-blog.csdnimg.cn/img_convert/759f254156783291456b805f34e637f6.png