node.js - 何时添加依赖项？在某些情况下我应该复制功能吗？

Question

我最近帮助了一个项目，我在其中添加了一个非常小的依赖项 - 事实上，它只包含一个正则表达式 ( https://www.npmjs.com/package/is-unc-path )。

我从项目开发人员那里得到的反馈是，如果可以轻松实现，他会尝试最大限度地减少第三方依赖项 - 如果我理解正确的话 - 他会要求我只复制代码而不是添加另一个代码依赖性。

对我来说，添加新的依赖项看起来就像将一些代码行放入存储库中的额外文件中。此外，如果代码需要更改，开发人员将收到更新通知。

仅仅是宗教思想驱使开发人员这样做吗？添加依赖项时是否可能存在任何成本(性能或空间等)？

Answer 1

我也曾与我的经理就第三方库发生过一些争议，问题更大的是他认为您应该对 node_modules 文件夹进行版本控制。

The source of any conflict usually is the ignorance.

他的论点是:

• 您应该向客户提供一个工作产品，而不需要他做任何其他工作，例如 npm install
• 如果在服务器上运行 npm install 时 github 和 npm 宕机，您会做什么？
• 如果您安装的库存在错误，谁将负责

我的论点是:

• 由于包依赖项的工作方式，版本控制 node_modules 不会起作用，每个库都会下载自己的 node_modules 依赖项，然后你的 git 存储库将迅速增长到数百个mb。部署会变得越来越慢，每次下载半GB的代码都需要时间。 NPM 确实使用模块缓存机制，如果没有更改，它不会无用地下载代码。
• left-pad 的问题很痛苦，但在 npm 实现了锁定系统之后，现在对于每个包，您只需锁定到特定的提交哈希。
• Github 和 npm 不只有单个实例服务，它们在云端运行。
• 安装依赖项时，您总是有一些想法，并且有社区最佳实践，通常它们会恢复为:1。存储库是否有单元测试。 2.下载数量 3。最新更新是什么时候。
• Node.js 生态系统是建立在模块化之上的， Node 如此流行并不是因为运气好，而是因为它的设计方式是创建模块并重用它们。有时在 Node.js 环境中工作感觉就像将乐高积木拼凑在一起并构建你的玩具。这是node.js发展超快的主要原因。人们只是重复使用东西。

最后他坚持自己的想法，我离开了这个项目:D。