最近，在哈布雷（Habré）上出现了一些有趣的文章。 第一个致力于解决
ES6的缩小问题，第二个致力于一般
有用的Webpack优化技巧 。
一切都很好，但是他们都绕过了将软件包分成ES6和ES5以便最小化和其他优化目的的问题。 通常，虽然有些人撰写和撰写
有关它的文章，但其他人（几乎所有人）却忽略了这种技术。
因为很久了。 贵的 并非如此。
但是，必须快速，廉价且笨拙。 也许您应该逆转进化。
主意
描述一个“想法”不是一个好主意。 最好描述一下它应该如何工作。 束形成过程应如何工作：
- 我有一个密码
- 我在“开发”浏览器下编译它
- 而且一切正常。
开发浏览器在这里-以便异步/等待，生成器，类，箭头函数等。 通常， 目标： babel中的esmodules 。
我不认识你，但我喜欢这个主意。 这里只是旧的浏览器还在我们中间，这种想法不太适合。
（因此，我们所有人都在嘶嘶作响地制作ES5，并用半兆字节的polyfills调味）而这正是需要解决的问题。权力下放
Devolution是一个小的cli实用程序，它将您的捆绑包编译成目标：esmodules并将其降级为es5，并在此过程中添加了所有必要的多文件。
简而言之，则：
- 所有的js脚本都是
- 通过一个定义了所需多文件的活动插件（fork useBuiltins：“用法”）在babel中运行。 这是快速的，因为没有转换。
- 对于每个文件，将收集它需要的所有polyphil（减去那些在主捆绑包中的polyphil），然后合并，遍历terser并添加到文件顶部。
- 每个文件都将通过swc运行，这是babel的生锈版本，它将代码降级到IE11可以理解的级别。 比babel快10-60倍。 它不支持各种插件，但这不是必需的-__________________已被使用。
- terser再次叠加在结果上，但是关闭了mangle（名称压缩），这又很快。
- 所有这些都是在工人中完成的。
我在难度级别不同的三个项目上运行了代码：
- 项目1，60个最终js文件（代码拆分）。 建立时间为400秒。 转移30秒。
- 项目2，最终的js文件1个（30mb）。 建立时间为120秒。 下放10秒。
- 项目3，最终的js文件1个（2mb）。 建立时间为20秒。 下放5s（在开始工作时，很多东西都丢失了）。
ESM捆绑包带来的好处有点奇怪：
- 一个项目丢失了400kb babel / polyfill。 那里没有使用过“过”浏览器芯片，在“ esm”中不需要抛光它们
- 一个项目由于生成器，异步/等待和类构造函数的代码更加紧凑而损失了10％
- 一个项目变得越来越胖，因为“松散”的babel转换有时会使代码更紧凑。 但是松散模式是一个危险的选择，而“ ES6”代码是“安全的”。
再一次：
- 我们采用ES6代码（更精确地讲，esmodule，为了速度目的，将/ const替换为var）
- 做它的ES5
- 抛向多友
- 分散爸爸，将符号链接添加到其他文件
- 我们将脚本与页面的连接更改为更加智能（IE11模块/ nomodule无法理解）
- 已完成-ESM适用于自定义仪表的85％，ES5适用于储罐中的仪表。
很简单 快点 真傻 我们取消了捆绑包的升级。 旧的浏览器！ 金-送达。
好吧，新的浏览器将收到一个几乎没有polyfill的捆绑软件，没有可怕的生成器转换和异步/等待，带有没有铃鼓的箭头功能（它们通常更快）。 总的来说，每个人都很高兴，这似乎是原本打算的。
github.com/thekashey/devolutionPS：实际上，目前，转储不使用swc ，因为它有时使代码无法正常工作-github.com/swc-project/swc/issues/280，Babel并没有那么慢-在swc被更正的地方在20秒内，babel可以在一分钟内完成。 有了“正常”的构建时间-从5开始-这是一大优势
PS：如果突然之间为什么要转移变得有趣了-
视频就在这里 。