这都是关于优点和缺点...以及什么是可能的。例如，React本身在整个项目中只能存在于一个版本中，所以你永远不应该包含它。
需要但未包含的依赖项应该作为peerDependencies添加到您的package.json中，并且使用者有责任下载它们。包含依赖项（作为dependencies，以便使用者自动下载它们）的缺点是使用者的捆绑包可能比需要的要大。在这里，您应该考虑谁将使用它;它是供您的组织内部使用还是供公众使用？您是否了解它将在其中使用的上下文？最好不要包含依赖项，因为这将为消费者带来更小的结果包，但如果依赖项不太可能出现在消费者的构建环境中，你不妨把它添加到你的软件包中，你想避免的情况是你的软件包中包含了消费者已经在使用的同一个软件包的不同版本;那么结果包可能包含大量代码的两个版本，这些代码可能被缩减为一个版本（如果消费者使用的版本和你的包使用的版本是兼容的）。当然，与小的不常见依赖相比，所有这些可能变得更糟。
举个例子：在我的组织中，我们使用Material-UI。我们有一个包含使用Material-UI的React组件的包，我们在其他项目中使用它。由于Material-UI将始终存在于项目中，因此将其包含在包中是不好的做法，即使这会使消费者承担更大的责任（us）将不同版本的包与我们在适用项目中使用的Material-UI版本对齐。如果有另一个消费上下文，将其包含在包中可能更有意义。
根据我的观点，你不应该捆绑你的软件包，因为这会让用户的树抖动变得更复杂，这适用于esm软件包（cjs是不可树抖动的），另一方面，在cjs中，捆绑的软件包是毁灭性的，因为它阻止了用户进行更具体的导入，以避免导入大量未使用的代码，例如。

import Comp from "package/Component"

代替

import { Comp } from "package"

几乎从来没有一个好的理由将依赖关系嵌入到库包中。这就是为什么你最终会在Web应用中拥有依赖关系的多个副本。最好的情况是，Web应用的包最终会变得不必要的臃肿。最坏的情况是，依赖关系在被复制时（例如React）会产生各种意想不到的行为。
防止依赖项重复的最有效方法是避免绑定库。如果你检查你的任何一个web应用项目中的node_modules文件夹，你可能会发现大量的第三方依赖项没有绑定。它们没有绑定不会对你的web应用产生影响。这证明了库绑定是毫无意义的。