发布到 npm 时，捆绑器提供什么价值？

Question

就上下文而言，我已经使用 Node.js 多年，但这是我第一次发布 Node.JS 包供其他人使用。不知道从哪里开始，我在谷歌上搜索了如何为打字稿执行此操作，并按照本文中的步骤进行操作。

推荐 tsup 作为捆绑器。它所做的事情之一是输出我的项目的两个版本。一种适用于 CommonJS 用户，一种适用于 ESM 用户。我看到了其中的价值。

但是捆绑输出的价值是什么？以下是我自己能想到的最好的理由，但我不确定它们是否有效：

1. 树摇晃。如果我按原样发布文件，则任何无法访问的代码都将包含在该包中，从而增加包的大小。
2. 这是在黑暗中进行的尝试，但也许如果我的包作为松散文件发布，用户可以

   import

   /

   require

   他们想要的任何文件，甚至是仅供内部使用的部分？ （到目前为止，我假设

   package.json

   main

   属性强制执行此操作。）

我想我假设可以发布我的包的 unbundled 版本，一个用于 CommonJS，另一个用于 ESM。让我知道这个假设是否不正确。

Answer 1

在 JS 出现任何类型的模块或依赖管理之前，捆绑就开始了浏览器的生命，但当 React 出现并提出“如果你不使用 JavaScript，而是需要编译为 JS 的东西怎么办？ ”以及任何想要使用 React had 来捆绑代码的人，因为无论如何它都必须通过 babel 运行（当时它还被称为 6to5）。这也是当人们“好吧，如果我们无论如何都要捆绑，我们也可以......”并添加死代码删除、资产散列、自动填充、CSS 编译、多目标转译到浏览器和节点，我们甚至将过去单独的后处理步骤添加到捆绑器中，例如缩小（这对于配备兆字节 RAM 的手机来说是必需的，因此将变量从

anchorManagerRouter

减少到

x

实际上做了一些事情）。

当然：代价是彻底破坏浏览器缓存数据的能力。一个角色在某处发生变化？这是一个全新的 1MB 下载，非常感谢。

然而，JS 成长了（或者更确切地说，不断发展）并获得了真正的模块系统，因此浏览器代码不再需要捆绑，终于可以再次依赖浏览器缓存。 “但现在您下载的将是 20 多个单独的文件！”确实如此，但事实上，我们恢复了浏览器缓存，再加上 QUIK 之类的东西，这一反对意见变得毫无意义。

捆绑对于生成通用库仍然有用，但是越来越多的人为不同的目标生成单独的捆绑包，因为它们可以单独优化，并且长话短说：捆绑本身在今天基本上毫无意义。

浏览器不需要它，Node、Deno 和 Bun 都支持现代 ESM 代码，因此只要您的代码不依赖于“DOM”或“文件系统”，您现在就已经在编写通用 JS只需要写 JS 即可。

当然，Node 从来不需要它，UMD 库只是一个方便的“部署一件事”解决方案。

在像

esbuild

或

tsup

这样的现代捆绑商执行的所有工作中，捆绑基本上是没有人真正需要的东西，它只是充当您想要或什至需要的所有其他东西的工具对你的代码做一些事情，并使所有其他事情，例如摇树（可以说有用，可以说没有），缩小（肯定不再有用），转译（当今使用构建工具的主要原因），对于编写这些工具的人来说更容易.

那么捆绑的价值是什么？绝对没有。但是，使用一个恰好输出捆绑包的捆绑器作为做其他所有有价值的事情的一部分有什么价值呢？字面意思是“能够做所有其他事情”。您可以自己在大型构建链中单独运行所有这些任务。这实际上就是早期所有这一切的运作方式。如果我们没有通过管道将数据从一个流传输到另一个流，因为使用 Node 的人们太喜欢流了。