可以说我们正在开发一个小型JavaScript库 L 。
代码在ES6中。要使用诸如debounce之类的实用程序功能，我们将lodash安装为依赖项。
在构建Webpack时，会编译代码，将 shaked lodash代码捆绑在一起，最后我们得到了一个漂亮的小javascript文件，我们希望将其发布并共享为npm包。
现在，package.json文件将lodash列为依赖项。但这仅在构建时适用，在生产中并不需要。
处理这种情况的正确方法是什么？
将lodash考虑为devDependency是否有意义？这样，只有webpack的externals是“真实的”依赖项吗？
还是我们应该在发布之前package.json篡改文件？
您知道处理这个问题的项目的真实例子吗？
答案 0 :(得分：1)
Webpack将项目代码与非外部 dependencies 的已使用代码“合并”到某个bundle.js文件中。然后，此文件与package.json文件一起发布到NPM，该文件列出了所有依赖项，而与外部依赖项或嵌入式依赖项无关。
dependencies（或optionalDependencies或peerDependencies）中引用的所有程序包代码均应为“生产”代码。
虽然devDependencies中的代码仅在“开发”时使用，因此是“开发”代码。根据这一原则，我认为将非外部依赖声明为开发依赖是不正确的。
但是，如果在已发布的package.json文件中均声明了所有嵌入式或外部依赖项，则运行时环境无法知道哪些真正的依赖项需要提供给程序包—程序包将在运行时 import 且更好地可用的软件包。
对于Node.js环境，通常不使用捆绑软件和Webpack，因此这永远不会成为问题-始终安装所有依赖项（绝不合并/捆绑）。
但是，如果您使用package.json文件来驱动某些Web程序包运行时环境，则当前发布的package.json中包含依赖项的方式是不合适的。 / p>
您可能想看看Pika Web's devDependencies package.json属性，该属性旨在解决一个类似的问题（即使他们的mojo是“没有Webpack的未来”）。他们还介绍了发布不同于签入文件的package.json文件的概念（如您所说，在发布之前篡改package.json）。
有趣的是，它看起来像一个相关的工具Pika Pack，引起了NPM的注意，并被认为become part of NPM。因此，也许，NPM已经意识到Web项目工作流程的特定软件包格式需求。