我的任务是开发一个NPM包，其中包含一个自定义组件(在本例中为Reaction组件)，该组件利用其他依赖项，如盘子、石板等.
我正在准备输出dist，但我不清楚这样做时的最佳实践是什么: 是否应该解析所有依赖项并将其Bundle 到一个大的.js文件中，或者可以忽略这一点？(我在这里使用ROLLUP RESOLE).我担心这会产生一个巨大的文件，包括所有依赖项的来源，但正如我所说的，我真的不熟悉这个过程……
另一方面，不解决这样的依赖关系而让组件的最终使用者这样做是常见的吗？(我在这里只是假设)
这一切都是关于利弊的...以及什么是可能的.例如，Reaction本身只能存在于整个项目的一个版本中，所以您不应该包含它.
需要但未包含的依赖项应在package.json中添加为peerDependencies，消费者有责任下载它们.包含依赖项的缺点(如dependencies，以便消费者自动下载这些依赖项)是消费者的Bundle 包可能比需要的大.在这里，你应该考虑谁会消费它；它是供组织内部使用还是供公共使用？你知道它将在什么环境下使用吗？最好不要包含依赖项，因为它会为使用者带来更小的结果包，但如果使用者的构建环境中不太可能存在依赖项，那么您最好将其添加到包中.您希望避免的情况是，您的软件包包含消费者已经使用的同一软件包的不同版本；然后，生成的Bundle 包可能包含大量代码的两个版本，这些版本可能会缩减为一个版本(如果消费者和软件包使用的版本兼容).当然，与小的不常见依赖项相比，大的公共依赖项可能会导致所有这些问题变得更糟、更可能.
例如:在我的组织中，我们使用Material-UI.我们有一个使用Material-UI的Reaction组件的包，我们在其他项目中使用它.由于Material-UI将始终存在于项目中，因此将其包含在包中是不好的做法，即使这会让消费者(我们)承担更高的责任，使不同版本的包与我们在适用项目中使用的任何版本的Material-UI保持一致.如果考虑到另一种消费背景，将其包括在一揽子计划中可能会更有意义.
根据我的说法，你永远不应该Bundle 你的包裹，因为这会让消费者的摇晃变得更加复杂.这适用于ESM包(CJS不可树摇动).另一方面，在CJS中，Bundle 包是毁灭性的，因为它阻止消费者进行更具体的导入，以避免导入大量未使用的代码.
import Comp from "package/Component"
而不是
import { Comp } from "package"