webpack笔记

1、压缩输出
我们将使用 -p(production) 这个 webpack 编译标记，来启用 uglifyjs 压缩插件。
从 webpack 4 开始，也可以通过 "mode" 配置选项轻松切换到压缩输出，只需设置为 "production"。

是因为使用了mode为生产模式，webpack会自动应用优化插件

webpack.optimize.UglifyJsPlugin
上面的压缩混淆插件在webpack版本小于3.0时，使用的是v0.4.6版本
在webpack4中计划使用1.0.0版本，最新的使用按照官网上的步骤来，下载安装uglifyjs-webpack-plugin

2、生产环境的配置
使用 webpack-merge 可以合并两个配置文件

3、指定环境
其实，当使用 process.env.NODE_ENV === 'production' 时，一些 library 可能针对具体用户的环境进行代码优化，从而删除或添加一些重要代码。
我们可以使用 webpack 内置的 DefinePlugin 为所有的依赖定义这个变量

概念：webpack是个资源打包器，能处理文件之间的依赖关系，并且生成一个文件，主要有以下四个概念
1.入口
2.出口
3.loader
4.插件

优化第一点：
1。作用域提升，webpack打包的时候会把每一个模块放到一个单独的闭包里面，如果有很多模块，闭包相对应的就多
所以，使用作用域提升可以减少闭包的数量。所以在webpack3.0中有ModuleConcatenationPlugin这个插件，来提升作用域，
但是需要注意的一点是只对es module语法生效，即import/export default

2.CommonsChunkPlugin 优化的思路就是通过将公共模块拆出来，最终合成的文件能在最开始的是加载一次，便于后续访问其余页面，直接使用浏览器缓存中的公共代码，这样无疑体验会更好。

new webpack.optimize.CommonsChunkPlugin({ // 这里的意思是将node_module中的模块抽离出来，成为vendor name: 'vendor', minChunks: function (module, count) { // any required modules inside node_modules are extracted to vendor return ( module.resource && /\.js$/.test(module.resource) && module.resource.indexOf( path.join(__dirname, '../node_modules') ) === 0 ) }, chunks:['app'] }), // // extract webpack runtime and module manifest to its own file in order to // // prevent vendor hash from being updated whenever app bundle is updated new webpack.optimize.CommonsChunkPlugin({ // 这里是从vendor里面把runtime 这部分代码抽离出来，名字是manifest name: 'manifest', chunks: ['vendor'] // 这个属性的意思是通过 chunk name 去选择 chunks 的来源。chunk 必须是 公共chunk 的子模块，指定source chunk，即指定从哪些chunk当中去找公共模块，省略该选项的时候，默认就是entry chunks // minChunks: Infinity // 这种写法和上面的写法效果一样，会马上生成公共chunk，但里面没有模块 }),

这样改变业务代码，就不用部署vendor代码。但是如果业务代码增加删除依赖还是会导致vendor变化，因为依赖的id变化了。

先来说一下各种教程以及文档中CommonsChunkPlugin提及到chunk有哪几种，主要有以下三种：

1. webpack当中配置的入口文件（entry）是chunk，可以理解为entry chunk
2. 入口文件以及它的依赖文件通过code split（代码分割）出来的也是chunk，可以理解为children chunk
3. 通过CommonsChunkPlugin创建出来的文件也是chunk，可以理解为commons chunk

在webpack4 legato 中已经被移除，新的分包工具使用 SplitChunksPlugin

从4.0版本开始CommonsChunkPlugin被移除且被optimization.splitChunks和optimization.runtimeChunk配置项代替.下面展示它们将如何工作.

webpack4以上无法使用  extract-text-webpack-plugin，用 mini-css-extract-plugin 代替

3。对于前两种方式 ，第三种是使用DllPlugin 和 DllReferencePlugin ，配合pwa，
dll插件则是预先打好一些三方库， 生成的dll文件和json文件，然后在build构建的时候根据json的映射去dll文件里面找到依赖的库，
也减小体积

总结下现在公司PC端使用的打包优化策略

1.预渲染，prerender-spa-plugin插件
2.公共部分打包 CommonsChunkPlugin

2019/02/26 日总结回顾
webpack低于4.0版本
使用commonsChunkPlugin来进行分包，将node_module中的三方库打包在一起，然后再将运行文件抽离，配合htmlwebpackplugin
将分好的包引入index.html
减少了app.js体积

dll和commons两个插件一起使用可能会造成重复打三方库的包

webpack插件原理：
在webpack构建的生命周期中，初始化时会遍历plugin选项中的插件，通过注册事件来监听，然后在生命周期中需要的时间点触发插件功能。

插件功能的实现，是通过操作 Webpack 对外暴露的事件钩子

总结流程就是：

• Webpack 的配置文件中所有依赖的插件通过 new XXXPlugin() 的方式填写在 plugin 配置项下，这些 Plugin 中注册了特定事件并提供了回调。
• 在 Webpack 初始化配置阶段将遍历 plugin 配置项并将每个 Plugin 都注册
• 接下来在Webpack 主流程运行时，每个关键生命周期点通过 call 方式触发特定事件，注册了特定事件的 Plugin 回调被调用，回调方法中被注入编译对象，可以获取到特定事件触发时编译对象的状态（即当前编译信息）并完成一些操作达到扩展目的。

实际上不仅仅是用户配置的 Plugin，在 Webpack 源码中很多的流程操作也是基于 Plugin 的方式实现的，所以可以说 Webpack 就是一个插件合集。

Webpack 的运行过程可以简单概括为以下几个步骤：

配置解析 -> 内置插件&配置插件注册 -> 确认入口获取依赖资源 -> 使用Loader翻译资源 -> 识别资源加载语句并递归的遍历所有资源 -> 封装依赖资源输出结果

接下来：
1.
vue-cli3有了基本的配置，只需要补充下一些优化操作

当开启extract
为true时，是应用了css提取插件

不应用时，css会内嵌到js代码中

webpack4和3的插件，也就是
mini-css-extract-plugin
和
extract-text-webpack-plugin
两者的对比差异如图

主要是第一点和第二点：支持按需加载和没有重复的编译
后者要配合OptimizeCSSPlugin 插件实现去除重复编译

摇树（tree-shaking）理解
1.何为摇树
2.如何使用

摇树是指把项目工程看成是一颗树，其中没有用到的函数或者模块啥的，是这个工程中不需要打包的东西，这时候
就可以通过摇树这个动作将不必要的东西舍弃

webpack4新增了一个 sideEffects 属性，，通过给 package.json 加入 sideEffects声明该 包/模块 是否包含 sideEffects(副作用)，从而可以为 tree-shaking 提供更大的优化空间。
如果你的代码确实有一些副作用，可以改为提供一个数组。

注意：

1.有没有副作用是相对于本身的包或模块 有没有改变外部的值，可以理解为是否是个纯函数。
这也就是因为babel转换的原因，导致代码肯定会有副作用，比如babel转换为了更符合ES6语义，转化个iife函数来封装类

以上可以知道，第二点的条件在babel之后肯定不能满足，有一个解决方案就是先摇树，然后再babel编译
这对我们自己的项目可以这个做，但是处理第三方库时，别人肯定是打好包的编译的
所以一些三方库也有自己的按需导入的处理

所以为什么打包库还是rollup好用
1.它支持程序流分析，在解析的时候就确定了哪些有没有副作用
2.它支持导出es模块的包