Parcel —— 新一代前端打包工具(很多吐槽,慎入)

是的,你没有看错,又是新一代前端打包工具。在开始介绍parcel这个可能很快流行起来的新秀之前,请允许我先进行一波很长的吐槽(不想听废话的同学直接跳到parcel简介开始看),这波吐槽是针对上一个被这么形容的打包工具。看哪呢!webpack,说的就是你!!!

两年前,也就是我大三刚刚决定躺进前端坑的时候,grunt+bower还留有余温,gulp正当宠。兴致勃勃、斗志昂扬、气宇轩扬…的我屁颠颠的找来了gulp的教程跟着写下了第一个demo,非常激动非常嘚瑟的在终端里敲下了gulp命令。这玩意比起grunt也简单太多了吧!!!

然而,我果然还是too young, too simplegulp还没捂热,webpack就杀出了重围,横空出世。不过老实讲,webpack这玩意虽然功能很强大,但是它的缺点实在是太明显了。太太太太难用/入手了!尤其是,它的官方文档简直一言难尽、罄竹难书(好吧,有点过了),但它的文档是真的烂。

对吐槽webpack感兴趣的同学可以戳这里: 一篇更官方更详尽的吐槽

尽管如此,架不住人家功能强大,普及迅速,尤其是在选择了Vue作为主要的前端框架之后,我还是乖乖的看起了webpack那看起来很像一坨那啥的文档,毕竟犹大的vue-cli用起来虽然很方便,但针对不同项目需求还是要有一定的调整。

然而(第二个然而,生活就是这么的令人惊喜),在我快要把webpack2.x文档看完的时候,rollup带着它的Tree-shaking走进了前端工作者们的视线中。更平缓的学习曲线、更高的打包效率使得rollup迅速流行,不过由于Vue的项目更适合使用webpack,所以对rollup我并没有花费什么时间。你问我为什么要说然而?因为可能是受到rollup的刺激,webpack3.x上线了。。。

你以为这就到头了吗?不,不是这样的。第三个然而,就在我终于腾出时间再次去品尝webpack3.x那依旧像一坨那啥的文档时,parcel来了。其实parcel也没有花费我多少时间,因为它真的很容易上手,不过这是后话。那么为什么我又说然而?因为可能是又被parcel刺激到了,webpack4.x推出了、推出了、出了。。。。。

好了,吐槽到这里就结束了。即使作为一个热衷于折腾新技术的作死星人,我也被前端界层出不穷的轮子搞得有点难受了(webpack同学请你放下手中的砖头)。

接下来,我们进入正题(你特喵的终于要进正题了),这是一波来自parcel的拯救。

parcel的简介

parcel的官网简介中,它主推的优势有:

  • 极速打包(从官方示例来看确实比webpack快不少)
打包工具 时间
browerify 22.98s
webpack 20.71s
parcel 9.98s
parcel(with cache) 2.64s

注:同一个应用在一台4核CPU的MacBook Pro16上的构建速度对比

  • 零配置(终于等到你,还好我没放弃)

  • 无需插件即可支持前端常见格式文件的打包(在webpack中需要各种loader)

  • 内置自动转换,包括babelpostcss

  • 友好的错误日志

至于其他的什么热模块替换都是标配功能,就不提了。我们来看看它是否和它的自我介绍一样。

parcel的使用

parcel命令参数

  • -p, –port 设置服务器端口
  • –https 在https协议上运行
  • -o, –open 自动在默认浏览器打开
  • -d, –out-dir 设置输入路径默认为dist
  • –public-url 设置服务器运行的路劲. 默认与–out-dir option 设置的相同
  • –no-hmr 关闭热模块替换
  • –no-cache 关闭缓存
  • -V, –version 版本信息
  • -h, –help 帮助信息

安装parcel

# Yarn
yarn global add parcel-bundler
# npm/cnpm
npm install parcel-bundler -g

初始化一个前端项目

# 创建文件夹
mkdir hello-parcel && cd hello-parcel
# 初始化package.json
yarn init -y # 使用yarn
# npm init -y # 使用npm

创建文件

<!-- index.html -->
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <meta http-equiv="X-UA-Compatible" content="ie=edge">
  <title>Document</title>
  <link rel="stylesheet" href="index.css">
</head>
<body>
  <div class="parent">
    <p class="child">webpack你真的不考虑重新写一下文档吗</p>
  </div>
  <script src="./index.js"></script>
</body>
</html>
/* index.css */
.parent {
  padding: 20px;
  background: #ccc;
}
.parent .child {
  text-align: center;
}
// index.js
const log = console.log
log('webpack我再问你一次,你真的不换文档吗')

运行parcel

parcel index.html --open

运行结果

修改一下index.js文件

// index.js
const log = console.log
log('webpack我再问你一次,你真的不换文档吗')
log('webpack我最后问你一次,你真的不换文档吗')

按保存后parcel会自动更新代码并将更新结果通知到订阅的机器上,而且更新速度极快

这上手速度和打包速度足以让人眼前一亮(webpack4.x同学,我随后就来宠幸你,希望你能争气一点)

同样的,修改index.css或者index.html都会触发热加载。

代码转换

接下来我们以具体的栗子看看在parcel如何转换代码

修改index.js

// index.js
const log = console.log
log('webpack我再问你一次,你真的不换文档吗')
log('webpack我最后问你一次,你真的不换文档吗')

function testAsync () {
  return new Promise((resolve, reject) => {
    try {
      setTimeout(() => {
        resolve('webpack你看看人家,配置多简单')
      }, 3000)
    } catch (e) {
      reject(e)
    }
  })
}

(async () => {
  const result = await testAsync()
  log(result)
})()
// 此处默认你看得懂代码

点击保存后切到浏览器控制台,很明显代码不能正常运行的。

因为目前几乎所有的浏览器都不支持async/await,这种情况下我们需要用babel转换代码。

首先是一些常规操作,先在根目录添加.babelrc文件

{
  "presets": [ "env" ],
  "plugins": [
    [
      "transform-runtime",
      {
        "helpers": false,
        "polyfill": false,
        "regenerator": true,
        "moduleName": "babel-runtime"
      }
    ]
  ]
}

添加依赖包

# yarn
yarn add babel-preset-env
yarn add babel-plugin-transform-runtime -D
# 如果是使用npm
# npm install babel-preset-env
# npm install babel-plugin-transform-runtime -D

好了,以上是使用babel转换代码所必须需要做的准备工作,我们来看看parcel需要做什么,如果是在webpack还有不少工作要做的。

wait,这是什么??

test

parcel,我还什么都没做,你你你你你,你怎么可以这么优秀!!!

原来零配置是真的存在的,被webpack折腾得心力憔悴的我一时无语凝噎。

从栗子中,我们可以看到,相对于webpackparcel最突出最让人心动的优点是:

  • 零配置完成项目构建
  • 内置各种常见的构建方案及依赖,无需自行安装
  • 支持以HTML为entry(入口),自动检测和打包资源
  • 默认支持模块热替换,开箱即用

反观webpack

  • 需要写一堆的配置
  • 安装额外的一大堆依赖(例如各种loader)

那我们可以说webpack就不如parcel了吗,webpack是否很快会被parcel取代?

答案是否定的,至少在很长一段时间内,parcel都很难撼动webpack目前的地位。

parcel并不完美

就我个人几个小时的体验过程来讲,我觉得parcel有待完善的地方有:

  • 不支持SourceMap

    对于复杂项目、可读性较低的代码,调试起来会力不从心

  • 不支持TreeShaking(按需加载)

    这是一个很多人注意到的点,那就是在大部分情况下,parcel打包后的文件体积都比webpack要大。

  • 还需要时间去打磨

    毕竟是刚开源不久的项目,很多地方有待完善,体验过程中遇到的坑也不少

  • 不灵活的配置

    虽然零配置是parcel最大的优点,但它需要为此牺牲一些代价,那就是灵活性

    • 无法控制部分文件的特殊处理
    • 无法控制输出文件的Hash值和名称
    • 无法控制输出目录的结构
  • 只能用于构建浏览器端的网站项目

相比之下webpack可以做到的事情就多很多了(但是,webpack同学,请你把文档重写一下好吗)

总结

目前来说parcel还有待完善,就我个人的话,中大型项目不建议各位使用于生产环境,那会是一条难以估量的踩坑之旅。我其实是一个蛮喜欢折腾的人,但是由于parcel刚推出不久,社区也还没有完善,这就导致踩坑的时候很难在网上找到解决方案,几乎都要靠自己去摸索。

但是,作为一名有追求的程序员,拥抱新技术、为新技术添砖加瓦也是义不容辞的,所以我鼓励大家在一些小项目中使用parcel,也希望parcel团队给力一点,早日将其完善,毕竟parcel还是深得我心的。

终于写完了。。。。

我接着去看webpack4.x文档了(逃

0%