在什么情况下选择 webpack？在什么情况下选择 rollup_Node.js

3条回答

2楼 · 2020-08-18 18:35

webpack主要用于以下两种情况：

1、代码拆分（Code Splitting）: 可以将应用程序分解成可管理的代码块，可以按需加载，这样用户便可快速与应用交互，而不必等到整个应用程序下载和解析完成才能使用，以此构建复杂的单页应用程序（SPA）；

2、静态资源（Static Assets）: 可以将所有的静态资源，如 js、css、图片、字体等，导入到应用程序中，然后由 webpack 使用 hash 重命名需要的资源文件，而无需为文件 URL 增添 hash 而使用 hack 脚本，并且一个资源还能依赖其他资源。

rollup主要用于：

1、要 js 高效运行。因为 webpack 对子模块定义和运行时的依赖处理（__webpack_require__），不仅导致文件体积增大，还会大幅拉低性能；

2、项目（特别是类库）只有 js，而没有其他的静态资源文件，使用 webpack 就有点大才小用了，因为 webpack bundle 文件的体积略大，运行略慢，可读性略低。

Dillion

3楼 · 2020-12-11 16:56

webpack和rollup都是JavaScript社区非常流行的一个打包工具。

关于什么情况下使用二者，可以这么说：对于应用使用 webpack，对于类库使用 Rollup。

因为如果你需要代码拆分(Code Splitting)，或者你有很多静态资源需要处理，再或者你构建的项目需要引入很多CommonJS模块的依赖，那么 webpack 是个很不错的选择。如果您的代码库是基于 ES2015 模块的，而且希望你写的代码能够被其他人直接使用，你需要的打包工具可能是 Rollup 。

我是大脸猫

4楼 · 2021-12-17 10:19

Webpack 始于2012年，由 Tobias Koppers发起，用于解决当时现有工具未解决的的一个难题：构建复杂的单页应用程序(SPA)。特别是 webpack 的两个特性改变了一切：

代码拆分(Code Splitting) 使你可以将应用程序分解成可管理的代码块，可以按需加载，这意味着你的用户可以快速获取交互性的网站，而不必等到整个应用程序下载和解析完成。当然你可以手动来完成这项工作，那么祝你好运。
静态资源(Static assets) 如图像和 CSS 可以导入到你的应用程序中，而且还能够被作为依赖图中的另一个节点。再也不用关心你的文件是否放在正确的文件夹中，再也不用为文件 URL 增添 hash 而使用 hack 脚本，因为 webpack 会帮我们处理这些事情。

Rollup 则是由于不同的原因被创建的：利用 ES2015 巧妙的模块设计，尽可能高效地构建出能够直接被其它 JavaScript 库引用的模块。其他的模块打包工具 – 包含 webpack – 通过都是将每个模块封装在一个函数中，将它们放在一个包中，通过浏览器友好的 require 实现，最后逐一执行这些模块。如果您需要按需加载，webpack 这类的打包工具非常合适。否则有点浪费，如果你有很多模块，它会变得更糟。

ES2015模块启用了一种不同的方法，这是真是 Rollup 使用的。所有的代码都放在同一个地方，然后一次性执行，从而生成更简洁、更简单的代码，从而启动更快。您可以自己使用 Rollup REPL 来查看它。

但是有一个权衡：代码拆分(Code Splitting)是一个更加棘手的问题，在撰写本文时，Rollup 还不支持。同样的，Rollup 也不支持模块的热更新（HMR）。而对于使用 Rollup 的人来说，最大的痛点可能是 – 它能处理大多数 CommonJS 文件（通过插件），然而有些东西根本不能转译为 ES2015 ，而 webpack 能处理所有你丢给它的事情。

那么我该用什么

到目前为止，希望这两个工具共同存在并相互支持的原因已经很明确了 – 它们有着不同的用途。总结一句话就是：

对于应用使用 webpack，对于类库使用 Rollup

这不是一个绝对的规则 – 事实上有许多网站和应用程序使用 Rollup 构建，同样的也有大量的库使用了 webpack 构建。但是，对于应用使用 webpack，对于类库使用 Rollup 是一个很好的经验法则。

如果你需要代码拆分(Code Splitting)，或者你有很多静态资源需要处理，再或者你构建的项目需要引入很多CommonJS模块的依赖，那么 webpack 是个很不错的选择。如果您的代码库是基于 ES2015 模块的，而且希望你写的代码能够被其他人直接使用，你需要的打包工具可能是 Rollup 。

给NPM包作者的建议：请使用 pkg.module !

在很长一段时间内，使用 JavaScript 库需要一些投机取巧，这是因为你和库作者使用的模块系统可能不一样，所以这就需要你和库作者在模块系统的选择上必须达成一致意见。举个例子，假设你使用的是Browserify打包工具，但是库作者更喜欢AMD模块系统，所以在你构建之前，你必须把库作者的模块系统替换成自己项目所使用的模块系统。虽然通用模块定义（UMD）格式类型固定，但是因为它没有在任何地方被要求强制执行，你永远不知道你下一步使用的模块系统是哪一种。

ES2015 改变了所有这一切，因为 import 和 export 是 JavaScript 语言的一部分。在将来，不会有歧义，模块系统会更加无缝地对接。不幸的是，因为浏览器（大多数）以及 Node 不支持 import 和 export ，我们仍然需要 UMD 模块系统过渡（如果你构建的文件只是用于Node，或许可以考虑CommonJS）。

通过在您项目的 package.json 文件（又称 pkg.module）中添加 "module": "dist/my-library.es.js" 入口选项，就可以同时为 UMD 和 ES2015 提供服务。
这很重要，因为 Webpack 和 Rollup 都可以使用 pkg.module 来尽可能构建出高效代码 – 在某些情况下，Webpack 以及 Rollup 甚至都能利用 tree-shake 特性来剔除项目中未使用的代码。