如何选择前端打包工具

关于打包这个问题是一个很有考究的学问,不论是bundle还是transform,存在即合理。这里我会以我个人的经历浅谈如何选择打包工具链。

在后续选择打包工具之前,我们应该先思考的是我们的工程服务的群体是什么样的,是类库还是应用工程。先想明白服务群体才能更好的选择工具。这里先给出我自己的结论如果不是应用工程大可不比bundle而是选择transform。关于这点我会在后续的部分进行详细展开。

这里我们以类库方向的工程进行切入点,在搭建一个类库工程gulp+babel是一个很好的解决方案。一个负责对disk进行IO,一个负责transform然后把结果给gulp进行输出。我们可以观看很多大型lib都是采取这么一个模式。在现代的工程我们不需要对一个类库进行打包因为打包以后在使用你会面临着二次打包,这一点我们从无数组件库便可窥得一二。因为在使用的时候我们往往是引入对应的组件部分而不是整个entry。所以transform的使用场景基本集中于此。那么不是组件库的库我们该怎么做？这里就以我在维护的hwebjs举例项目地址,因为这个项目足够小它不需要webpack这样的重型工具，browserify提供的模块功能足够我们使用。因此我们就会使用他。

相较于babel，swc,tsc+磁盘IO的操作,有些时候我们不约而同的看到了rollup+api-extractor的组合方案，这里以我个人角度来看,这些往往适合于纯js的库。比如vue。我们先看rollup的描述将无数小的模块聚合成一个大的模块。那么在这些大型js库往往需要把这些模块整合方便输出不同环境下的包,这点是纯transform所做不到的,具体的最佳实践我们可以看看vue,出色的利用了rollup完成不同模式的打包。

说完了类库的选择，就剩下了工程相关的了。关于vite,webpack,parcel都是作为一些上层解决方案这里给出我的经验,现阶段除了webpack都不靠谱。vite给我最大的感受就是缝合了rollup但是顺带把rollup的bug也一起缝进来了。这种强依赖于上游的包。在面对复杂的前端应用工程往往无法面面俱到。因此我们看到了在面对低版本兼容的需求下vite是无法升任的。这一点也和rollup有关系。因为rollup在设计之初就不是为web应用开发服务的。反观webpack这种虽然大但是在面对复杂的场景他是游刃有余的。无论是从社区生态还是近乎完美的打包支持webpack占据着绝对的地位。webpack的抽象程度之所以复杂是因为承担的场景不是其他的打包工具能比拟的这一点也是经常被人诟病,但是推倒重来我们真的可以做得更好吗？再谈谈新晋的宠儿parcel。我有幸使用过一次给我的感觉也是和vite差不多也不再展开。至于已经死去的snowPack大概是我对bundleless的最后一丝幻想了吧。