⑴ 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工作流程
Webpack 的运行流程是一个串行的过程,从启动到结束会依次执行以下流程 :
1.初始化参数：从配置文件和 Shell 语句中读取与合并参数,得出最终的参数。
2.开始编译：用上一步得到的参数初始化 Compiler 对象,加载所有配置的插件,执行对象的 run 方法开始执行编译。
3.确定入口：根据配置中的 entry 找出所有的入口文件。
4.编译模块：从入口文件出发,调用所有配置的 Loader 对模块进行翻译,再找出该模块依赖的模块,再递归本步骤直到所有入口依赖的文件都经过了本步骤的处理。
5.完成模块编译：在经过第 4 步使用 Loader 翻译完所有模块后,得到了每个模块被翻译后的最终内容以及它们之间的依赖关系。
6.输出资源：根据入口和模块之间的依赖关系,组装成一个个包含多个模块的 Chunk,再把每个 Chunk 转换成一个单独的文件加入到输出列表,这步是可以修改输出内容的最后机会。
7.输出完成：在确定好输出内容后,根据配置确定输出的路径和文件名,把文件内容写入到文件系统。
在以上过程中,Webpack 会在特定的时间点广播出特定的事件,插件在监听到感兴趣的事件后会执行特定的逻辑,并且插件可以调用 Webpack 提供的 API 改变 Webpack 的运行结果。
⑶ 从 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