捆绑并发布 NPM 库。解决所有依赖项并将它们包含到捆绑包中是否很常见？

Question

我的任务是开发一个带有自定义组件（在本例中为 React 组件）的 NPM 包，该组件利用了其他依赖项，例如 Plate、slate 等。

我正在准备输出dist，但我不清楚这样做时的最佳实践是什么：是否应该解析所有依赖项并将其捆绑到一个大 .js 文件中，或者可以忽略它？（我在这里使用汇总解析）。我担心这会产生一个巨大的文件，包括所有依赖项的来源，但正如我所说，我真的不熟悉这个过程......

另一方面，不解决此类依赖关系并让组件的最终使用者这样做是否常见？（我这里只是假设）

Answer 1

这都是关于优点和缺点......以及什么是可能的。例如，React 本身只能存在于整个项目的一个版本中，因此您永远不应该包含它。

需要但未包含的依赖项应添加到peerDependencies您的中package.json，并且消费者有责任下载它们。包含依赖项（以便dependencies消费者自动下载它们）的缺点是消费者的包可能比它需要的更大。这里你应该考虑谁会消费它；它是供您组织内部使用还是公共使用？您知道它的使用环境吗？最好不要包含依赖项，因为它会为消费者提供更小的结果包，但如果依赖的依赖项不太可能出现在消费者的构建环境中，您也可以将其添加到包中。您要避免的情况是您的软件包包含消费者已在使用的同一软件包的不同版本；那么生成的捆绑包可能包含大量代码的两个版本，这些代码可能会减少为一个版本（如果消费者使用的版本和您的包使用的版本兼容）。当然，与小的不常见依赖项相比，对于较大的常见依赖项，所有这一切都可能变得更糟，并且更有可能发生。

举个例子：在我的组织中，我们使用 Material-UI。我们有一个使用 Material-UI 的 React 组件包，我们在其他项目中使用它。由于 Material-UI 将始终出现在项目中，因此将其包含在包中是不好的做法，即使它会给消费者（我们）带来更高的责任，使不同版本的包与任何版本的 Material-UI 保持一致我们在适用的项目中使用的。考虑到另一种消费环境，将其包含在包装中可能更有意义。

据我所知，你永远不应该捆绑你的包裹，因为这会让消费者的摇树变得更加复杂。这适用于 esm 包（cjs 不可进行树摇动）。另一方面，在 cjs 中，捆绑包是毁灭性的，因为它阻止消费者进行更具体的导入以避免导入大量未使用的代码，例如

import Comp from "package/Component"

代替

import { Comp } from "package"