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

Question

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

代码是ES6的。为了使用一些实用功能，例如debounce，我们安装 lodash 作为依赖项。

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

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

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

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

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

Answer 1

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

\n\n

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

\n\n

但是，如果所有依赖项（嵌入的或外部的）在已发布的package.json文件中均等声明，则运行时环境无法知道哪些是需要提供给包 \xe2\x80\x94 的真正依赖项该包将在运行时导入，并且最好可用。

\n\n

对于 Node.js 环境，通常不使用捆绑包和 Webpack，因此这永远不会成为问题 \xe2\x80\x94 所有依赖项始终安装（从不合并/捆绑）。

\n\n

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

\n\n

您可能想看看Pika Web 的 devDependencies package.json财产，它旨在解决类似的问题（尽管他们的魔力是“没有 Webpack 的未来”）。他们还引入了发布与签入文件不同的文件的概念package.json（正如您所说，在发布之前篡改文件package.json）。

\n\n

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

\n