假设我们正在开发一个小型 javascript 库 L。
代码在 ES6 中。为了使用一些实用功能，比如debounce，我们安装 lodash 作为依赖项。
在构建时，webpack 会转译代码，捆绑 tree Shaked lodash 代码，最后我们会得到一个漂亮的小 javascript 文件，我们希望将其作为 npm 包发布和共享。
现在，package.json 文件将 lodash 列为依赖项。但这仅在构建时是正确的，在生产中并不是真正需要的。
处理这种情况的正确方法是什么？
将 lodash 视为 devDependency 是否有意义？因此，只有 webpack 的 externals 才是“真正的”依赖？
或者我们应该在发布之前以某种方式篡改package.json 文件？
你知道处理这个问题的项目的任何真实例子吗？
【问题讨论】：
标签： javascript npm package.json
Webpack 将项目的代码与非外部依赖项使用的代码“合并”到某个bundle.js 文件中。然后将该文件与package.json 文件一起发布到 NPM，其中列出了所有依赖项，独立于外部或嵌入。
dependencies（或optionalDependencies，或peerDependencies）中引用的所有包代码都应为“生产”代码。
而devDependencies 中的代码预计仅在“开发”时使用，因此是“开发”代码。在这个原则下，我认为将非外部依赖声明为开发依赖是不正确的。
但是，如果所有依赖项，无论是嵌入的还是外部的，都在已发布的package.json 文件中进行了同等声明，那么运行时环境就无法知道哪些是需要对包可用的真正依赖项——包将在运行时导入并且更好地可用的那些。
对于 Node.js 环境，通常不使用捆绑包和 Webpack，因此这从来没有成为问题 — 所有依赖项始终安装（从不合并/捆绑）。
但是，如果您使用package.json 文件来驱动一些web-packages 运行环境，那么依赖项 目前包含在已发布的package.json 中的方式并不合适。
你可能想看看 Pika Web's devDependencies package.json 属性，它旨在解决类似的问题（尽管他们的魔力是“没有 Webpack 的未来”）。他们还引入了发布与签入文件不同的package.json 文件的概念（如您所说，在发布之前篡改package.json）。
有趣的是，它看起来像一个相关的工具，Pika Pack，引起了 NPM 人员的注意，正在考虑become part of NPM。所以，也许，NPM 已经意识到 Web 项目工作流的特定包格式需求。
【讨论】：