javascript - 发布仅包含非捆绑依赖项的 NPM 包

Question

假设我们正在开发一个小型 javascript 库 L。

代码在 ES6 中。要使用一些实用功能，例如 debounce，我们将 lodash 安装为依赖项。

在构建时，webpack 转译代码，捆绑 tree shaking lodash 代码，我们最终得到一个漂亮的小 javascript 文件，我们希望将其作为 npm 包发布和共享。

现在，package.json 文件将 lodash 列为依赖项。但这仅在构建时适用，在生产中并不真正需要。

处理这种情况的正确方法是什么？将 lodash 视为 devDependency 有意义吗？因此，只有 webpack 的 externals 才是“真正的”依赖？

或者我们是否应该在发布之前以某种方式篡改 package.json 文件？

你知道处理这个问题的项目的任何真实例子吗？

Answer 1

Webpack 将项目代码与非外部依赖项 使用的代码“合并”到某个bundle.js 文件中。然后将此文件与 package.json 文件一起发布到 NPM，该文件列出了所有依赖项，无论这些依赖项是外部的还是嵌入式的。

dependencies(或optionalDependencies，或peerDependencies)中引用的包的所有代码都应该是“生产”代码。devDependencies 中的代码预计仅在“开发”时使用，因此是“开发”代码。在这个原则下，我认为将非外部依赖声明为开发依赖是不正确的。

但是，如果所有依赖项，无论是嵌入式的还是外部的，都在发布的 package.json 文件中同等声明，则运行时环境无法知道哪些是真正需要的依赖项对包可用 - 包将在运行时导入并且最好可用的那些。

对于 Node.js 环境，通常不使用 bundle 和 Webpack，因此这从来都不是问题 — 所有依赖项始终安装(从不合并/捆绑)。

但是，如果您使用 package.json 文件来驱动某些网络包运行时环境，依赖项 当前包含在已发布的包中的方式。 json 不合适。

您可能想看看 Pika Web's devDependencies package.json 属性，旨在解决类似的问题(尽管他们的魔咒是“没有 Webpack 的 future ”)。他们还介绍了发布与 checkin 文件不同的 package.json 文件的概念(如您所说，在发布之前篡改 package.json)。

有趣的是，它看起来像一个相关的工具 Pika Pack，引起了 NPM 人员的注意并正在考虑 become part of NPM .因此，也许，NPM 已经意识到 Web 项目工作流的特定包格式需求。