这是我在找 Webpack 自动配置生成 时,发现的彩蛋?

既然别人把他们放在一起,估计挺好用的?你看 rollup, brunch 就没放上去

点开说明文档,此处划重点 “利用多核处理提供极快的性能,并且你不需要进行任何配置。”

这不就是我们在 Webpack 使劲折腾的问题,以及 brunch 的那套方案?甚至更少的配置。

看Demo 和测试还算 Ok;但是会不会和 brunch 一样,接口不完善,生态又辣鸡,于是就完全跑不起来。

而且第一眼看到这个名字,我还以为时 preact,大概加班太多,神智有点不清不楚。

初探

看上去提供了 3 个主要的命令

  • parcel 本地服务器测试
  • parcel watch 监听文件变化,自动编译
  • parcel build 编译

很通俗的几个操作,没发现亮点,除了不要加 dev,默认为 dev server 之外

看文档描述,他和 webpack 不同大概是入口,webpack 秉承着一切都是 JS 的原则,啥东西都打包成 JS;虽然 webpack 可以通过 loader 加载奇奇怪怪的 entry,但是输出就比较麻烦,我想用 webpack 打包 markdown 生成静态站的伟大构想,只能通过自定义 Plugin 或者各种骚操作实现,因为设计上所有的 loader 最后都会把文件转化为 JS 模块;preact 的中间状态暂时不知道,毕竟这只是个初探。

所以总结一下:

告别几百行复杂的 webpack 配置,内置了大量 webpack 配起来十分蛋疼的东西(比如 HMR、dev server、各种 loader)

所以可能将来的构建工具就 2 种,一种叫 webpack一种叫 webpack 最佳实践
抛开配置复杂度的问题(可以内部封装),但是性能优化只能重新设计插件和使用机制,这块 webpack 是历史遗留原因;而新实现的这些最佳实践,也都没法复用 webpack 的生态,所以要是生态没起来,迟早得 GG

比如 Brunch,随便找个啥插件都没有,这生态也不知道用他的意义是啥?说的就是 Ambari 那个项目。

深入尝试一下

对于这种工具包,最直接的使用方式就是帮他拓展功能;通过拓展功能熟悉 API,就能把它作为一个黑箱来揣测内部实现机制和可拓展性之类的问题。

比如之前通过写Webpack Loader 和 Pluginrollup-plugin-output 大致分析了一下,webpack 和 rollup 的实现机制和拓展机制。

得出如下没什么卵用的结论:

rollup 弱化了 webpack 复杂的插件机制,因为插槽少,所以拓展性受限,但是相对性能提高,且配置减少。

这里我们可以类比其他前端娱乐圈的项目,比如 Atom 和 VSCode,有些设计的确出彩,可拓展性极强;但是是否具有必要性?是不是我们只是需要一个简单的核心,或者能替换核心的接口。

而不是提供一个啥都没有的空框架,然后利用框架增加新特性?特指 Webpack,或许将来会出现,webpack 做快速实现,然后能导出插件调用关系的高性能构建工具,也就是对 webpack 本身的编译和优化,让他作为工具使用的时候,脱离其可拓展性和动态特性。

对了,这里是不是应该尝试开发 parcel 插件来着。

找了几个别人的插件看看,这里我们借鉴 webpack 插件的开发原理,拓展包含 loader 和 plugin,loader 提供的是对新文件解析的支持,而 plugin 提供的是新的流程。至于可视化的流程,应该看看我之前的文章。一切构建都可以被 Gulp 包括,因为他只是个任务流程定义工具,这些构建工具最后都会被切分成一堆插件提供的任务,一个包含上下文的函数入口。

对于上面的叙述,主要为了说明为什么我们选择新模板(markdown)静态文件压缩(parcel-plugin-static-zip)这2个模块来分析,pug 只是新 loader,应该会转化为 HTML 进入通常的流程,而 zip 这个应该会介入 parcel 流程,在合适的地方放钩子,进行压缩。

好了,对应的就是上面的地址,markdown 是一个新的资源,实现注册和解析就完成了任务。

而 zip 是个插件,他用到了 parcel 的接口,来监听任务完成的事件。

剩下的就没必要深入了