webpack编译zip包

⑴ webpack基本使用

step1: 创建一个项目录
注意：项目名一般 不要带中文
step2: 创建 package.json

或者：

step4: 处理第三方文件
html文件中需要引入多个js文件或者第三方模块(例如：jquery.js)，只引入项目js入口文件( main.js ),其他js文件均在入口文件中导入。导致可能JS文件中使用了浏览器不识别的高级语法:

总结：webpack可以做两件事情况：

step5: 配置入口文件和出口文件
每次修改js文件，手动输入命令： webpack 入口文件路径 -o 出口文件路径 重新打包， 每次都要输入入口文件和出口文件，麻烦。可以在项目目录下建立配置文件 webpack.config.js ,指定入口文件和出口文件:

重新打包：

step6: 实现自动打包编译
每次修改js文件，都要手动重新打包，还是麻烦？使用 webpack-dev-server 这个工具，来实现自动打包编译的功能。

webpack-dev-server 这个工具，如果想要正常运行，要求在本地项目中必须安装 webpack

在 package.json 文件中配置命令：

在终端中执行命令：

注：在终端执行 npm run dev ，就等于执行 webpack-dev-server 命令。这将在node中开启一个服务器，并且立即打包。每次修改文件，ctrl + s 保存文件,webpack-dev-server工具自动监听文件改变，并且自动打包。

改变文件引用路径：
执行上述命令后终端会有类似信息输出：
【 Project is running at http://localhost:8080/ 】——webpack-dev-server工具将项目托管到localhost:8080/端口上

【webpack output is served from /】——打包好的文件通过localhost:8080/bundle.js访问

【Content not from webpack is served from C:UsersyfbDesktop前端学习案例4.27wabpackDemo_1src】——不是通过webpack打包的文件，则是以src为根目录访问。

该项目根目录下并不存在bundel.js文件，我们可以认为webpack-dev-server把打包好的文件，以一种虚拟的形式托管到了咱们项目的根目录中，虽然我们看不到它，但是可以认为和 dist、src、node_moles平级，有一个看不见的文件，叫做 bundle.js。其实是为了频繁打包，提高效率，直接把打包的文件放在内存中。

因为项目托管到新服务器，现在应该访问的是 该服务器 下的项目，文件引用路径也要改变:

step7: 自动打开浏览器进行访问、配置端口号、指定托管的根目录、热重载（只是修改补丁，不重新生成整个bundle.js文件）
在 package.json 中配置命令，并重启服务器：

step8: 使用 html-webpack-plugin 插件
使用 --contentBase 指令的过程比较繁琐，需要指定启动的目录，同时还需要修改index.html中script标签的src属性。

安装 html-webpack-plugin 插件：

在 webpack.config.js 配置文件中配置插件：

html-webpack-plugin 插件的两个作用：

step9: 处理样式文件
html文件中需要引入css、less、sass样式文件。默认情况下，webpack处理不了这些样式文件。

处理css文件：

处理less样式文件

⑵ webpack的打包配置-1修改版

1、现在本地创建项目目录

2、然后在index.html中写入html的结构
3、想要先安装jquery，先npm init -y一下， npm install jquery -S 【项目目录安装，必须是小写的jquery，否则会报错】，在index.html引入main.js
4、在main.js中写入内容如下：

使用webpack处理一下，转换成浏览器可以识别的文件 ：
a: 先全局安装一下webpack=> npm install [email protected] -g
b: 在终端中执行： webpack ./src/main.js【要处理的文件的目录】 ./dist/bundle.js【要输出的文件的目录以及文件名】 ，会在dist中生成一个bundle.js文件，然后在 index.html中引入的main.js文件改成 bundle.js
这样的话每次打包时候都需要执行 webpack ./src/main.js ./dist/bundle.js
c: 为了不手动指定入口和出口文件，在项目根目录中新建一个webpack.config.js（基于node的，所以** **node.js的命令都可以识别）

这样的话，就可以在终端中直接执行命令：webpack就可以直接打包了，但是还有个小问题。就是它不 会自动更新，需要手动刷新一下。下面我们就来解决这个问题。来配置webpack-dev-server

4、使用webpack-dev-server实现自动打包编译

直接安装webpack最高版本的时候，可能会遇到报错的情况，如果对于版本没有要求的话，可以降低版本：
npm install [email protected] -D 如果还会有报错出现的话，可以试试使用cnpm安装

需要先在终端中安装webpack-dev-server：具体操作如下：
4.1 npm/cnpm install webpack-dev-server -D 出现下面的提示：【其实此步骤容易出现报错，所以呢，把webpack-dev-server版本修改为@2.9.1=>[email protected]时，就不会报错】

4.2 npm/cnpm install webpack -D 【此步骤也是容易出错的，所以安装的时候要和上边的版本保持一致，[email protected]版本】
4.3 需要在package.json中配置dev

最后直接执行：npm run dev运行成功，但是需要注意的是此时打包成的bundle.js文件不是磁盘中存在bundle.js文件，而是一个与src dist node_mole同级的看不见的文件，在index.html引入的路径也要修改以下=》<script src="/bunlde.js"></script>

此时，正常打包，但是不自动打开浏览器

发布出来，方便自己查看，有什么不对的地方，希望留言纠正修改。（程序员菜鸟一枚）

⑶ 从 Webpack 到 Snowpack, 编译速度提升十倍以上——TRPG Engine迁移小记

原文地址: http://moonrailgun.com/posts/74598ef5/

TRPG Engine 经过长久以来的迭代，项目已经显得非常臃肿了。数分钟的全量编译, 每次按下保存都会触发一次 10s 到 1m 不等的增量编译让我苦不堪言, 庞大的依赖使其每一次编译都会涉及很多文件和很多包，长时的编译时间大大降低了开发效率与迭代速度。

经过一段时间的考察，我选择了 Snowpack 作为解决方案。与 Webpack 不同的是，除了第一次的全量编译以外， Snowpack 的增量编译不会涉及到庞大的 node_moles 文件夹, 准确来说只会编译变更文件本身。甚至于如果没有对依赖进行变更，下次的全量编译会直接动用之前编译的文件缓存，不需要花时间等待 node_moles 的编译。

为什么会这么快？这是由于 Snowpack 本身的实现与设计哲学有关的。相比 Webpack , Snowpack 利用了现代浏览器的本身的 mole 系统，跳过复杂的模型之间的组织编译过程而只关注于变更文件本身的编译，这样当然快了。

拿 Snowpack 官方的一张图来说:

snowpack 的最我译单位是文件，而 webpack 的最我译单位为 chunk , 而 chunk 还需要额外的计算, 不论是编译部分还是编译后的组装部分。snowpack的设计逻辑天生决定了她的速度。

优化前(使用 webpack ):

全量编译:

增量编译:

全量请求用时:

优化后(使用 snowpack ):

全量编译:

增量编译:

(看不到编译用时，但是体感在1s内. 而且该效果在电脑运行其他应用时更加显着)

全量请求用时:

以上测试是保证电脑在空闲时间，且保存与操作内容为同一文件

该用时已经是平时操作的最快时间，为此我的MBR重启了一次强制清空了swap空间, 实际表现会更加显着

因为文件依赖于浏览器的耗时，而浏览器需要串行请求依赖，因此耗时会更加长

但实际使用中使用snowpack会更加优秀。因为其相比webpack会大大节约电脑资源。在webpack编译时会占用大量的电脑资源，会影响到其他操作

TRPG Engine 算是非常经典的 Webpack 应用了, 使用了各种Loader。光通用配置就有250+行，各种优化配置，各种 alias。等等长时间迭代积攒下来的配置，因此毫不意外的会遇到很多问题与坑。

以下是我遇到的问题与解决方案:

Snowpack虽然作为一个新兴的打包工具，目前尚不是非常完善, 功能也没有webpack这样丰富与齐全。但是它的新的打包设计对于有一定规模的前端应用还是非常优秀的。能极大提升开发效率。不失为一种好的解决方案。当然最后输出还是需要使用webpack对其进行一定的优化，毕竟原生的mole支持目前浏览器的支持度还没有达到覆盖一个理想的地步 https://caniuse.com/es6-mole

最后这是我最后提交的 pr

⑷ webpack 怎么直接实时编译输出文件

使用webpack编译打包react是非常便捷的。这也是人们常用的一种方式。但是在使用过程中，一定要注意一个细节，那就是webpack和babel-loader的安装位置。react安装当然，使用react必须先安装react和react-dom，其安装方式很简单（前提是我们必须安装有npm）。#npminstallreactreact-dom–savereact安装就这样简单，其实react和react-dom就是相当于js类库。但是我们需要解析器来解析react的语法。react解析器babel安装babel安装的位置是我们这篇文章的目的。babel有两种安装的位置：一种是全局安装，一种是本地安装——也就是安装在项目目录下的node_moles下。#npminstallbabel-corebabel-loaderbabel-preset-react–save-dev//本地安装#npminstallbabel-corebabel-loaderbabel-preset-react–g//全局安装一般情况下我们选择本地安装，这样便于管理。打包工具webpack的安装同样，webpack的安装位置也是这篇文章描述的所要注意的点。当然，它也有两种安装的位置：全局安装和本地安装。#npminstallwebpack–save-dev//本地安装#npminstallwebpack–g//全局安装如果选择本地安装，那么在使用的时候较麻烦一些，我们需要在命令前加上路径。所以一般情况下都是全局安装，这样就可以在任意位置直接使用。这里我们选择全局安装。这样才能出现我们将要说的问题。webpack配置文件编写安装完webpack以后，下面来编写webpack配置文件webpack.config.js。这里我不写全部，只写加载loader部分。代码一mole:{loaders:[{test:/\.js$/,loader:'babel',query:{presets:['react']}}]}编译过程中出现的错误好了，到了关键的地方了。现在我们整个系统的配置是这样的：babel安装到本地，webpack安装到全局位置，webpack配置文件如代码一所示。接下来我们就要编译打包我们的项目。#webpack执行该命令以后，你会发现出现如下的错误：ERRORin(webpack)/~/node-libs-browser/~/process/browser.jsMolebuildfailed:Error:Couldn'tfindpreset"react"relativetodirectory"/node/lib/node_moles/webpack/node_moles/node-libs-browser/node_moles/process"……这也就是说找不到babel-preset-react。好了，说了这么多终于在这里引出了我们将要讨论的问题（这里大家不要嫌我啰嗦，为什么出现这种问题，其原因总要弄清楚。什么样的配置会出现这种问题，了解以后才容易上手解决）。解决问题的方式出现上述问题以后，我们有这样三种方式可以解决。方式一要解决这个问题很简单。我们知道，出现这个问题是因为bable和webpack安装的位置不同，所以找不到babel-preset-react。因为在配置文件中有这样一段代码。query:{presets:['react']}好了，既然知道是安装位置不同，那我们可以将babel安装在全局位置，这样这个问题不就解决了吗。#npmremovebabel-corebabel-loaderbabel-preset-react–save-dev//首先移除原先安装的babel#npminstallbabel-corebabel-loaderbabel-preset-react–g//全局安装没错，问题解决了。但是我们不推荐使用这种方式。因为这样不便于管理，所以还是使用其他的方式。方式二此种方式和方式一大同小异。方式一是改变babel的安装位置，而这里是改变webpack的安装位置。原先webpack是安装到全局位置的，所以找不到安装到本地项目目录下的babel-preset-react。因此我们可以改变webpack的位置。#npmremovewebpack–g//移除原先的webpack#npminstallwebpack–save-dev//将webpack安装到本地位置——也就是项目目录下的node_moles中#ln–s/项目根目录/node_moles/webpack/bin/webpack.js/usr/bin/webpack//为了使用webpack方便，在这里我们在/usr/bin目录下建立软连接（也就是快捷方式）//这样我们就可以在任意位置直接使用webpack命令了。此时我们已经改变了webpack的安装位置。现在二者同在项目目录下安装。所以可以正确编译了。此种方式较方式一，我个人比较推荐这种方式，这样比较方便管理。但是，这种方式也不是没有弊端。如果我们有多个项目，那我们就需要在每个项目下都安装webpack，那岂不是很麻烦。所以这种方式也不是很好。方式三该方式应该说是最值得推荐的，因为不需要改变webpack和babel的安装位置。webpack还是在全局位置，babel还是在本地项目位置下。我们需要做的就是修改webpack的配置文件，在代码一的基础上添加一句代码。代码二mole:{loaders:[{test:/\.js$/,loader:'babel',exclude:/node_moles/,query:{presets:['react']}}]}

⑸ Webpack 怎么用

1. 为什么用 webpack?
他像 Browserify, 但是将你的应用打包为多个文件. 如果你的单页面应用有多个页面, 那么用户只从下载对应页面的代码. 当他么访问到另一个页面, 他们不需要重新下载通用的代码.
他在很多地方能替代 Grunt 跟 Gulp 因为他能够编译打包 CSS, 做 CSS 预处理, 编译 JS 方言, 打包图片, 还有其他一些.
它支持 AMD 跟 CommonJS, 以及其他一些模块系统, (Angular, ES6). 如果你不知道用什么, 就用 CommonJS.
2. Webpack 给 Browserify 的同学用
对应地:
browserify main.js > bundle.js

webpack main.js bundle.js

Webpack 比 Browserify 更强大, 你一般会用 webpack.config.js 来组织各个过程:
// webpack.config.js
mole.exports = {
entry: './main.js',
output: {
filename: 'bundle.js'
}
};

这仅仅是 JavaScript, 可以随意添加要运行的代码.
3. 怎样启动 webpack
切换到有 webpack.config.js 的目录然后运行:
webpack 来执行一次开发的编译
webpack -p for building once for proction (minification)
webpack -p 来针对发布环境编译(压缩代码)
webpack --watch 来进行开发过程持续的增量编译(飞快地!)
webpack -d 来生成 SourceMaps
4. JavaScript 方言
Webpack 对应 Browsserify transform 和 RequireJS 插件的工具称为 loader. 下边是 Webpack 加载 CoffeeScript 和 Facebook JSX-ES6 的配置(你需要 npm install jsx-loader coffee-loader):
// webpack.config.js
mole.exports = {
entry: './main.js',
output: {
filename: 'bundle.js'
},
mole: {
loaders: [
{ test: /\.coffee$/, loader: 'coffee-loader' },
{ test: /\.js$/, loader: 'jsx-loader?harmony' } // loaders 可以接受 querystring 格式的参数
]
}
};

要开启后缀名的自动补全, 你需要设置 resolve.extensions 参数指明那些文件 Webpack 是要搜索的:
// webpack.config.js
mole.exports = {
entry: './main.js',
output: {
filename: 'bundle.js'
},
mole: {
loaders: [
{ test: /\.coffee$/, loader: 'coffee-loader' },
{ test: /\.js$/, loader: 'jsx-loader?harmony' }
]
},
resolve: {
// 现在可以写 require('file') 代替 require('file.coffee')
extensions: ['', '.js', '.json', '.coffee']
}
};

5. 样式表和图片
首先更新你的代码用 require() 加载静态资源(就像在 Node 里使用 require()):
require('./bootstrap.css');
require('./myapp.less');

var img = document.createElement('img');
img.src = require('./glyph.png');

当你引用 CSS(或者 LESS 吧), Webpack 会将 CSS 内联到 JavaScript 包当中, require() 会在页面当中插入一个 ｀<style>标签. 当你引入图片, Webpack 在包当中插入对应图片的 URL, 这个 URL 是由require()` 返回的.
你需要配置 Webpack(添加 loader):
// webpack.config.js
mole.exports = {
entry: './main.js',
output: {
path: './build', // 图片和 JS 会到这里来
publicPath: 'http://mycdn.com/', // 这个用来成成比如图片的 URL
filename: 'bundle.js'
},
mole: {
loaders: [
{ test: /\.less$/, loader: 'style-loader!css-loader!less-loader' }, // 用 ! 来连接多个人 loader
{ test: /\.css$/, loader: 'style-loader!css-loader' },
{test: /\.(png|jpg)$/, loader: 'url-loader?limit=8192'} // 内联 base64 URLs, 限定 <=8k 的图片, 其他的用 URL
]
}
};

6. 功能开关
有些代码我们只想在开发环境使用(比如 log), 或者 dogfooging 的服务器里边(比如内部员工正在测试的功能). 在你的代码中, 引用全局变量吧:
if (__DEV__) {
console.warn('Extra logging');
}
// ...
if (__PRERELEASE__) {
showSecretFeature();
}

然后配置 Webpack 当中的对应全局变量:
// webpack.config.js

// definePlugin 接收字符串插入到代码当中, 所以你需要的话可以写上 JS 的字符串
var definePlugin = new webpack.DefinePlugin({
__DEV__: JSON.stringify(JSON.parse(process.env.BUILD_DEV || 'true')),
__PRERELEASE__: JSON.stringify(JSON.parse(process.env.BUILD_PRERELEASE || 'false'))
});

mole.exports = {
entry: './main.js',
output: {
filename: 'bundle.js'
},
plugins: [definePlugin]
};

然后你在控制台里用 BUILD_DEV=1 BUILD_PRERELEASE=1 webpack 编译. 注意一下因为 webpack -p 会执行 uglify dead-code elimination, 任何这种代码都会被剔除, 所以你不用担心秘密功能泄漏.
7. 多个进入点(entrypoints)
比如你用 profile 页面跟 feed 页面. 当用户访问 profile, 你不想让他们下载 feed 页面的代码. 因此你创建多个包: 每个页面一个 "main mole":
// webpack.config.js
mole.exports = {
entry: {
Profile: './profile.js',
Feed: './feed.js'
},
output: {
path: 'build',
filename: '[name].js' // 模版基于上边 entry 的 key
}
};

针对 profile, 在页面当中插入 <script src="build/Profile.js"></script>. feed 页面也是一样.
8. 优化共用代码
feed 页面跟 profile 页面共用不要代码(比如 React 还有通用的样式和 component). Webpack 可以分析出来他们有多少共用模块, 然后生成一个共享的包用于代码的缓存.
// webpack.config.js

var webpack = require('webpack');

var commonsPlugin =
new webpack.optimize.CommonsChunkPlugin('common.js');

mole.exports = {
entry: {
Profile: './profile.js',
Feed: './feed.js'
},
output: {
path: 'build',
filename: '[name].js'
},
plugins: [commonsPlugin]
};

在上一个步骤的 script 标签前面加上 <script src="build/common.js"></script> 你就能得到廉价的缓存了.
9. 异步加载
CommonJS 是同步的, 但是 Webpack 提供了异步指定依赖的方案. 这对于客户端的路由很有用, 你想要在每个页面都有路由, 但你又不像在真的用到功能之前就下载某个功能的代码.
声明你想要异步加载的那个"分界点". 比如:
if (window.location.pathname === '/feed') {
showLoadingState();
require.ensure([], function() { // 语法奇葩, 但是有用
hideLoadingState();
require('./feed').show(); // 函数调用后, 模块保证在同步请求下可用
});
} else if (window.location.pathname === '/profile') {
showLoadingState();
require.ensure([], function() {
hideLoadingState();
require('./profile').show();
});
}

Webpack 会完成其余的工作, 生成额外的 chunk 文件帮你加载好.
Webpack 在 HTML script 标签中加载他们时会假设这些文件是怎你的根路径下. 你可以用 output.publicPath 来配置.
// webpack.config.js
output: {
path: "/home/proj/public/assets", // path 指向 Webpack 编译能的资源位置
publicPath: "/assets/" // 引用你的文件时考虑使用的地址
}

⑹ Webpack打包流程细节源码解析（P2）

此篇博客紧承上一篇，上片讨论了我们的webpack整个处理单个文件的流程，这一节主要说一说webpack的文件打包问题，其实本身是比较简单的，但是有异步块和html-plugin的加入，使这个步骤变得尤为复杂，这里先介绍几个重要的概念：

上一节中，我们成功的对每个文件进行了处理，并通过了process的方法对所有入口文件以及他们的依赖文件进行了处理，获得了最初的依赖文件列表，现在我们就可以对资源的依赖进行优化处理，本片的内容将从webpack/lib/Compiler.js:510的断点开始逐步的对源码进行分析

在seal之前，由于一轮compilition已经执行完成，先调用finish方法进行收尾处理与之对应的是我们注册的finish-moles事件，

这里我们首先看到的又是index.ejs这个老朋友，由于他是单独的文件经过了loader处理没有获得额外的处理函数的依赖，所以最终这里看到的mole实际上是它的js外壳包起来的ejs文件，此阶段也还没有进行资源hash的注入等等

这里有一个FlagDependencyExportsPlugin进行了操作，听名字可能就听出来了，他是对我们资源中的export使用进行一个标志的作用， 和我们最终做出的tree shaking效果可能是相关的

调用seal事件处理

处理我们的preparedChunk，这个东西是我们刚好在进行addEntry的时候添加上的不知道你们还记不记得，中途就没有添加过新的，所以讲道理，一个entry是只用一个的，但是这里使用了一个数组不知道有什么用意

然后把这个入口模块添加到了block里面，过后打包也是从block里面拿数据，block里面的东西会被打包成为单独的文件，但是还是工作在之前的上下文中，这里可以通过看一下这里的import即是我们之前在路由文件中通过import函数设置引入的动态加载路由资源

进入到函数，就开始处理我们之前做好准备的block了，这里这是一个不断处理依赖的过程，但是没有使用递归的做法，毕竟文件太多了，不断的进行递归会浪费很多空间，取而代之的是使用queue进行记录，处理过程中不断把新的需要处理的模块放到queue里面等待下一步处理

在每一步的处理中

处理完这一波循环依赖旅历过后，本身的依赖树结构变得扁平化，之前一层一层的模块通过dependency连接起来作为一个树的结构，而现在变成了顶层最终的几个chunk

可拆正搜以看到我们最终在这个入口（entry）设置清穗中拿到了9个chunk，她们都有_moles属性，我们的所有依赖都是放到这里面的，是用的一个Set进行存储，其中的依赖关系则是通过origins和reason等标识进行模块间关系的连接的

还可以将我们的入口chunk和异步加载的chunk进行一些对比（上面的是入口文件），下面的chunk中出现的origins就是指向我们之前的router那个mole

这个图里也可以看到，两个chunk实际上按照自己的路子搜集了所有的依赖，结果导致了_moles的文件数量都达到了一千多个，这就是我们常使用的CommonChunk插件需要处理的地方了，稍后进行讨论

这轮处理我们成功的把主要的入口mole和异步加载的模块区分开了，然后开始按照类似的逻辑处理我们的第一个入口模块

这个时候拿到chunkDependencies进行处理，这就是之前那个存储block的东西，但是有个很奇怪的地方，就是这里面居然只有三个chunk，而不是和上面的一样是9个也不是只有一个入口模块，这就让人无从下手了（我异步加载的模块并不是一样的，而且这些模块之间没有没相互依赖）

喜闻乐见进行第二次处理，首先取出一个chunk拿到对应的存储在value中的deps，对每一个项目添加上了他们的parent，但是有个组件就是用来removeParent的

在RemoveParentMolesPlugin这个插件中，针对每个mole都做了处理，看看这些模块在哪些chunk之中有被使用到，把他们所存在的chunks按照id记录下来，并改变她们的reason为几种统一的chunk组合数组。这样就做到了每个mole知道了自己被哪些chunk使用，但是从之前的单一reason到现在的多reason具体不知道有什么用（恩。。可能是为作用域提升做准备）

然后嘛，移除空的模块，不需要多解释

然后这层处理就算完啦，主要进行了模块的依赖梳理和拆分，并为他们添加上了指向父节点的指针（话说之前不是有origins吗）

对模块进行排序工作，不过只是按照索引进行排序罢了，那个按照出现概率进行排序处理的插件不是在这里工作的

又是那个flag的插件进行了处理，但是只是把所有模块的used设置为了true，还有为一些被依赖的mole设置上他们的usedExports为true

ChunkConditions插件用于监视模块上是否有chunkCondition函数，并返回他的执行结果，如果有模块的此函数返回了false，那么将会重写这个模块（重写即是重新添加进入parent的链接以及reason等的设置）并且还会返回true，到至此过程不断执行直至condition全部OK

RemoveParentMolesPlugin这个插件的作用有点玄乎，看样子是对每个chunk进行处理，看对于多个chunk中都有的某一些mole，会直接把他们的reason设置为主要的入口chunk，而后把当前chunk中的mole移除掉（话说这个事情不是应该Common来做吗）

然后移除所有空的模块，再就是移除重复的模块了（话说一直用set神他妈还会有重复的）

然后进行各种优化，比如出现的概率大的放到前面，这里还是做了mole和chunk两种优化，也是有毛病，就像我们的react项目中可以知道react的使用次数最多，那么他就被放到了最钱前面，紧随其后的是echart等

HashedMoleIdsPlugin插件为我们的模块计算出它的id，默认是通过md5进行计算，解出来的是base64的，而且计算的参数也仅仅只是通过模块的libId进行hash，而这个libhash只是相对位置，连绝对的都不是，所以算下来这个东西能够当成单个文件的hash了

applyMoleId，到这里你可能会想，诶之前不是已经设置好每个元素的id了吗，为什么还要搞这么个函数专门处理，我们在上一个生成id的时候实际上得到的id是根据我们的设置进行了截断的，实际上拿到的hash碰撞的概率非常大，我们看看下面这个筛选的处理就可以知道，1885个模块里面竟然又3个重复的id，这种时候就要特殊处理了

执行sortItemsWithMoleIds依据id进行排序，不只是最外面的chunk，就连reason里的id也会被重新排序，也是蛮逗的，这里直接用的是id做比较并没有判断类型，也就是说把数字和字符串会混到一起，就算你是class也会拿valueOf出来比较，想想还是蛮刺激的，不过其实比较完成也没有太特殊的用途就这么随意一点也好

中间一些处理recordId的我忽略掉了

然后开始处理hash了，这里的hash具体使用了哪些参数和长度是多少呢

可以在此阶段添加hashSalt即噪声，给hash值添加一些特征

进入mainTemplate的处理函数中，添加了一些字符串参数和数字参数，并且调用了mainTemplate的hash插件，但是她们的执行过程并不是保证我们最后生成的文件中能够有结果的hash值，便于请求对应的资源文件，而是仅仅在hash的过程中添加了一些干扰的路径参数等

最终一轮hash下来，chunk会得到自己的renderHash，而compilation会得到一个针对编译过程的hash，这个hash就跟我们的所有资源扯上关联啦，所以每次都是新的

创建模块资源咯~

这些文章写的都有点水，相当于是阅读源码时候做的笔记了，看看图个乐子吧

⑺ webpack打包原理

webpack打包原理是根据文件间的依赖关系对其进行静态分析，然后将这些模块按指定规则生成静态资源，当 webpack 处理程序时，它会递归地构建一个依赖关系图(dependency graph)，其中包含应用程序需要的每个模块，然后将所有这些模块打包成一个或多个 bundle。

webpack有两种组织模块的依赖方式，同步、异步。异步依赖将作为分割点，形成一个新的块；在优化了依赖树之后，每一个异步区块都将作为一个文件被打包。

webpack有一个智能解析器，几乎可以处理任何第三方库。无论它们的模块形式是CommonJS、AMD还是普通的JS文件；甚至在加载依赖的时候，允许使用动态表require("、/templates/"+name+"、jade")。

(7)webpack编译zip包扩展阅读

在使用webpack构建的典型应用程序或站点中，有三种主要的代码类型：

1、团队编写的源码。

2、源码会依赖的任何第三方的library或"vendor"代码。

3、webpack的runtime和manifest，管理所有模块的交互。

runtime 包含：在模块交互时，连接模块所需的加载和解析逻辑；包括浏览器中的已加载模块的连接，以及懒加载模块的执行逻辑。