NPM 仅安装后依赖项
Posted
技术标签:
【中文标题】NPM 仅安装后依赖项【英文标题】：NPM postinstall-only dependencies 【发布时间】：2020-12-28 21:17:22 【问题描述】：我正在使用 git 分发一个内部 TypeScript NPM 包。由于我不想在我的存储库中包含构建文件，因此我在安装包时使用安装后操作来构建包：
"postinstall": "tsc -p tsconfig.json"
要构建我的包，需要一些依赖项（例如 TypeScript）。但是，当我将它们添加为开发依赖项时，它们在安装后阶段不可用，因此我必须将它们添加为常规依赖项。
所以我的问题是：
在我的 package.json 中将这些构建依赖项声明为常规依赖项有什么缺点吗？ 如果是这样，在通过 git 安装的 NPM 包中表达仅构建依赖项的首选方式是什么？【问题讨论】：
你应该使用"prepair" 钩子，仅供参考，用于主要通过 git 分发的包。
【参考方案1】：
我不得不强烈反对 zamber 的回答。将所有依赖项声明为 prod 依赖项有相当大的缺点。 如果你这样做，任何安装你的包的人也会在他们的 node_modules 文件夹中安装你所有的开发依赖项。在这一点上，这似乎不是什么大问题，但想象一下，如果每个人都这样做。还要记住，安装您的项目的不仅仅是人，还有安装使用您项目的任何依赖项的人。
node_modules 文件夹已经很大并且 npm install 已经花费了很长时间。如果每个人都添加开发依赖项作为产品的带宽、处理能力和硬盘空间需求将显着提高。
在我的许多项目中，真正的依赖项非常少，但有很多大型开发依赖项：构建依赖项（如 typescript）、测试 jest 或 jasmine 等依赖项、linting 依赖项，甚至用于自动化测试的整个浏览器。除了您之外，没有其他人需要这些依赖项，因此不必为它们支付时间和硬盘空间。
发布 TS 库的方法是在发布之前构建。这意味着不需要任何开发依赖项。
【讨论】：
【参考方案2】：在我的 package.json 中将这些构建依赖项声明为常规依赖项有什么缺点吗？
我不这么认为。无论哪种方式，您都需要它们来构建包，因此除非您提交构建的文件，否则无法绕过它。
或者，您可以只提供源文件并让用户负责构建。
另一个选择是分支它。假设master 有你的源文件，创建一个dist 分支并且永远不会将它合并回master，然后在dist 提交构建的文件，当你想要发布一个版本时合并master 到dist、构建、提交、推送。这将使您能够更好地控制更新并使消费者更轻松。
如果您正在创作一个将在其他项目中使用的库，通常可以在您的存储库中保留工件。为用户节省安装时间和麻烦。
此安装后构建方案的一个可能缺点是您的使用者可能会使用 package.json resolutions 重载您的构建依赖项。
【讨论】：
以上是关于NPM 仅安装后依赖项的主要内容，如果未能解决你的问题，请参考以下文章