我知道在 package.json 中做类似的事情:
....
...
"dependencies" : {
"some-node-module" : "*"
}
这是一个坏主意，因为您基本上告诉 Node 始终将此模块更新到其最新版本，即使您的代码可能无法处理除此特定模块的当前版本之外的任何其他版本。
所以我应该做这样的事情:
....
...
"dependencies" : {
"some-node-module" : "3.4.1"
}
这基本上告诉 Node 始终使用我的代码构建的模块版本。
问题
我有一个应用程序，我首先在本地测试过。应用程序现已构建，并使用 package.json 依赖项，npm 已在本地安装了所有相应的 Node 模块我的应用程序的根文件夹(与全局相反，在一些不起眼的文件夹中，我无法立即访问并且与此应用程序无关 - 我只是不喜欢 Node 模块的全局安装 - 我发现它们..“摘要”)。
鉴于所有 Node 模块现在都安装在本地，我的 package.json 中的 Node 模块依赖项部分现在不是多余的吗？
我的意思是，如果发生某些情况并且 npm 不可用或找不到模块的特定版本怎么办？
独立于动态 Node 模块安装并且首次在本地安装所有内容而不必使用 package.json 依赖项不是最好吗？
最佳答案
npm 安装和更新
"you're basically telling node to always update this module to its latest version"
软件包不会自动更新。 "*" 唯一会出现问题的是当您第一次通过 npm install 安装项目时。或者当您通过 npm update 手动运行更新时.
我个人更喜欢选择模块的特定版本，而不是使用任何通配符，但即使如此，也存在一些问题......这就是 npm Shrinkwrap 存在的原因。
npm 收缩包装
下一个问题:
basically tells node to always use the version of the module that my code was built around
有点正确。假设您使用您最喜欢的模块的 1.2.3 版本，并且 package.json 反射(reflect)了这一点，但模块本身是一个 package.json对另一个模块的依赖，并且使用"*"...因此，当您安装时，新的内部依赖项和通配符可能会破坏您认为已“锁定”的模块向下'。
看到问题了吗？硬编码版本控制顶级版本，但不强制执行任何低于该版本的内容...并且如果您依赖的模块作者(或者他们依赖的模块)使用通配符，您不能 100% 确定事情会成功。
要严格执行版本，您需要使用 npm shrinkwrap 。 (文档的链接提供了更多背景信息，如果您的项目使用多个非常简单的模块，这有助于理解。)
现在...你的问题。
你说:
I mean, what if something happens and npm is not available or the specific version of a module can't be found?
根据这个答案的前两部分，现在应该很清楚，在 package.json 中显式列出依赖项并没有什么坏处，因为 Node 不会每次都检查东西应用程序运行的时间。当调用特定操作(安装、更新等)时，npm 使用 package.json，但即便如此，它也是一个手动触发器。
虽然情况各不相同，但我很少能想象在 package.json 中省略依赖项是一个好主意。如果您最终不得不重建该项目，您就会遇到麻烦。如果这个项目太好了你想分享它，你就会遇到麻烦。哎呀，如果这是为了工作而你想去度假并且需要将其安装在另一台机器上......你就会有麻烦了。
因此，考虑到初始安装后，依赖项不会产生负面影响...使用 --save 或将依赖项添加到 package.json 中。 future 的你会感谢你。 :)
关于Node.js - 本地安装模块时是否需要 package.json 依赖项？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/32311935/