初探Parcel

昨天趁有点时间看了前不久很火的构建工具Parcel，这里说下初步使用的感觉，尤为是将其放到实际项目中和Webpack进行比较。

 

1、前言

首先说下笔者目前的技术栈。最近的前端项目主要以管理后台为主，技术栈都是React.js + Redux + React-Router + Antd + Create-react-app这套，版本均为较新的版本。Webpack构建工具体系由Create-react-app脚手架初始化，因默认打包功能不太丰富，笔者eject出打包相关的配置文件，在原基础上添加了额外功能：

1. 代码分割与模块异步懒加载

2. 模块按需加载

3. less以及postcss的支持

4. 字体文件的打包

5. JS模块热替换(原始只支持样式的热替换)

6. dev-server(Express)正向代理、代理的destination参数接收、HTTPS的启用以支持h/2协议

前5项考虑到资源大小、首屏性能、样式的兼容以及书写的方便、总体开发的便捷性，是不管在dev或是production环境都会有的。

第6项正向代理是由于笔者这个项目的底层是分布式文件存储系统 + 基于Cluster模块的Node.js集群 + MongDB分片式集群 + HA集群，dev环境是跑在Vagrant Centos7.x虚拟机集群里的，production环境是直接跑在Centos7里的，对操做系统以及机器硬件依赖大。数据流从文件存储系统底层传递到Node.js层再传递到Web前端，且Web前端和Node.js后端只有基于HTTP、Websocket的交互，在开发时出于工程化的考虑，直接和底层环境隔离，进而方便调试，无需到Vagrant起的虚拟机中部署修改后的前端代码，也无需Fiddler或者Charles代理服务端的文件到本地文件，或是依赖Jekins持续集成。只须要Webpack的dev-server代理到Node.js上层Nginx便可，在'npm start'后跟上协议 + 跑有Node.js服务的IP + Node.js进程监听的端口号便可，会将此参数传给dev-server的正向代理配置。

因而可知，若是说你的项目很简单，CLI提供的初始功能便可知足需求，正是如此Facebook在Create-react-app中，直接把最基本的构建有关的文件都放到了node_modules中，只暴露出了命令，使用者根本不须要去维护构建有关的文件。若是说业务需求较复杂会对工程化要求高，若是CLI工具初始化的Webpack打包体系的初始功能不知足业务需求，也是须要额外加入不少东西的，而且须要咱们手动去配置。

Webpack的功能确实强大，相对于Browserify来讲，Webpack真的是大而全。但相似于字典的API文档和各类loader与plugin运用，无形中提升了整个工具链的技术门槛，对于大多数没有深刻研究的开发者来讲，只能是知道Webpack的基本用法和要点的概念，再用到具体的loader和plugin的时候再去查看文档，而后过必定时间不使用基本又会忘掉。对于初学者来讲而要准确的说出某个loader或者plugin的功能和配置方法是有必定难度的。并且Webpack的每一个大版本之间也存在必定的功能和API上的变化，当你熟悉了这个版本后，下一个版本就来了...... 有没有一种"铁杵磨成针"的感受呢？

目前前端的开发模式、技术栈与工具链基本都相同，为何不能在构建工具内部就给出能适配大多数业务需求的默认的配置而省去烦人的手动配置呢？因此Parcel号称的零配置的吸引力是很大的。

 

2、Parcel初探

笔者新起了一个demo项目，但功能复杂度模拟真实项目：

按照Parcel官方要求作了最基础的package.json和.babelrc配置，其余都应用零配置默认的项，不作额外配置。Parcel版本为1.9.3.

index.html为Parcel打包的入口，依赖src/index.js文件。

src文件夹为源资源目录：

src --
       |--  components      存放高度抽象的公用组件

　　 |--  redux      存放redux初始化、action、reducer

       |--  styleSheets      存放公共和各组件的样式less

       |--  views      存放业务视图组件

       |--  index.js      JS入口文件

路由、代码分割、Antd UI组件按需加载、Redux相关、样式等功能都支持。这是使用Parcel打包过程：

 

打包后的结果：

这是打包过程当中对计算机硬件资源的利用：

 用笔记本开发的同窗请注意散热...

 

3、使用Webpack打包同一个项目

 

笔者再起了一个项目，技术栈和上个段落中的项目相同，但使用前言中提到的Webpack工具链打包该项目。懒得修改index.html的目录，因而新建了public文件夹把index.html放进去，并删除了<script>引入，由'html-webpack-plugin'插件注入JS脚本依赖。

结果以下：

 

 

这是打包过程当中对计算机硬件资源的利用：

 

4、有区别处的对比

1. 打包速度

首先当前版本Parcel在速度上绝对比Webpack未使用HappyPack时要快上不少，从计算机CPU使用率能够看出，笔者计算机CPU是i7 4770HQ 4c/8t，在执行Parcel构建时，8个线程均被使用上了，虽然超线程技术产生的额外线程的是引用率并比不上物理核心，但已经很不错了。第二次使用Parcel打包后，能够看到速度较上次还有明显提高，这是由于第一次打包生成了.cache目录的缘由，能够记录上一次打包的状态。反观Webpack仅仅只能使用4个物理核心的线程，对核心线程的利用率也并不高，对超线程技术支持不友好，并且耗时很长，拖拖拉拉，固然使用上了HappyPack后会有必定改善。这就是Parcel打包速度快的缘由。

2. 打包质量

在零配置下Parcel彷佛没有相似于TreeShaking的按需引用技术，而致使打包出来的资源大小要大不少。总所周知，Webpack的TreeShaking可以抖掉引入包中并未真正使用的模块，可是parcel并无，咱们在disk文件夹下的src.js的下，发现了以下代码：

笔者只在代码中引用了Button组件，可是整个Antd UI库的全部组件都被打包进来了，这个srcjs文件异常庞大。若是说咱们在loadsh的时候，引入了所有loadash，看在它不大的份上还情有可原，可是整个UI库的引入，致使大小提高到了4Mb，以及和使用Webpack打包出的main.js(200KB)作比较，就难以接受了。

3. 使用场景的支持性

在纯的web前端项目中，Parcel彷佛没有什么问题和报错，而当咱们打包Node.js项目时，会产生由于有些require写法不支持而报错等问题，固然打包后端醒目可能不是Parcel的目的。而Webpack在这方面作得较好，支持构建的应用较为丰富得多，基本上使用JS的各类项目都支持。

 

5、经过HappyPack给Webpack打包加速

直接上个代码例子：

没有使用的HappyPack的状况：

使用之后，须要在plugins配置下增长对应的HappyPack实例：

加入HappyPack后，在打包时，CPU使用率较以前高出不少，打包速度有明显提高。

可是笔者在HappyPack实际使用中还遇到了两个问题：

1. 对图片资源的打包，会使图片资源数据被破坏，致使图片资源没法正常使用。这个问题笔者在HappyPack的Github项目Issue里也看到有人提出过，但并无找到明确的解决办法。

2. 对extract-text-webpack-plugin支持很差，这个插件堪称webpack里面最不稳定的一个插件。

固然以上问题可能和笔者所使用的Webapck有关的loader和plugin自身有关联。

 

6、总结

Parcel的零配置打包着实让人眼前一亮，可是限制仍是不少的，而且为了零配置而抛弃掉了不少灵活配置，致使对打包过程和资源输出有自定义需求的时候还必须本身去修改或者使用额外的插件。那么这样一来岂不是又回到了Webpack等的老路上去了。总之若是没有太复杂的自定义的构建业务需求、也没有引用某些重型UI库，使用Parcel可以让整个打包过程很清爽，反之请使用Webpack。若是以为Webpack构建太慢，可使用HappPack增长多进程处理以达到模拟多线程的目的，充分利用计算机CPU超线程技术的功能(若是支持的话)。但HappyPack并不能完美适配全部loader或plugin，这点也不能忽视。固然这也不是必须的，由于又会有谁在不停地打包开发环境的代码呢？并且通常大型项目，也会直接使用CLI脚手架工具搭建环境，像React.js官方的Create-react-app同样，构建相关的文件都没有暴露出来的，提供能够直接使用的'npm start'、'npm run build'等命令。若是你不须要自定义修改，从某种程度来讲脚手架工具就是零配置的。新的Webpack4.0大版本也支持零配置，若是你不须要额外的自定义功能的话。

因此Parcel还需打磨，它还不具有让开发者放弃现有构建工具的吸引力。