我的任务是开发一个带有自定义组件(在本例中为react组件(的NPM包，该组件利用了其他依赖项，如平板、石板等。
我正在准备输出dist，但我不清楚这样做时的最佳实践是什么：是应该解析所有依赖项并将其绑定到一个大的.js文件中，还是可以忽略这一点？(我在这里使用汇总解析(。我担心这会产生一个巨大的文件，包括所有依赖项的来源，但正如我所说，我真的不熟悉这个过程。。。
另一方面，不解决这种依赖关系并让组件的最终消费者这样做是否常见？(我只是假设(
这一切都是关于优点和缺点。。。以及什么是可能的。例如，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"
在库捆绑包中嵌入依赖关系几乎从来都不是一个好的理由。这就是你在网络应用程序中获得多个依赖项副本的原因。充其量，网络应用程序的捆绑包最终会变得不必要地臃肿。在最坏的情况下，当依赖关系被复制时(例如React(会产生各种意想不到的行为。
防止依赖项重复的可靠方法是完全避免绑定库。如果你在任何一个网络应用程序项目中检查你的node_modules文件夹，你可能会发现许多没有捆绑的第三方依赖项。他们缺乏捆绑功能不会对你的网络应用程序产生影响。这证明了绑定库是毫无意义的。