我知道在package.json中做了类似的事情：
....
...
"dependencies" : {
"some-node-module" : "*"
}
是一个坏主意，因为您基本上告诉节点始终将此模块更新为其最新版本，即使您的代码可能无法处理除此特定模块的当前版本之外的任何其他版本。
所以我应该做这样的事情：
....
...
"dependencies" : {
"some-node-module" : "3.4.1"
}
这基本上告诉节点始终使用我的代码所围绕的模块版本。
问题
我有一个应用程序，我首先在本地测试。该应用程序现已构建，使用package.json dependencies，npm已在我的应用根文件夹下本地安装了所有相应的节点模块（而不是全局，在一些不起眼的文件夹中，我没有立即访问权限，这与此应用程序无关 - 我根本不喜欢节点模块的全局安装 - 我发现它们......“抽象”）。
鉴于所有节点模块现在都安装在本地，不是我的package.json中的节点模块依赖项现在是多余的吗？
我的意思是，如果发生了什么事情并且npm不可用或者找不到特定版本的模块怎么办？
最好是独立于动态节点模块安装，只是第一次在本地安装所有内容而不必使用package.json依赖项吗？
答案 0 :(得分：1)
npm install＆amp;更新
“您基本上告诉节点始终将此模块更新为其最新版本”
套餐不会自动更新。 "*"成为问题的唯一时间是您第一次通过npm install安装项目或通过npm update手动运行更新时。
我个人更喜欢选择一个特定版本的模块，而不是使用任何通配符，但即使这样，也有一些问题......这就是npm shrinkwrap存在的原因。
npm shrinkwrap
下一个问题：
基本上告诉节点总是使用我的模块版本 代码是围绕
构建的
Sorta true。假设你使用你最喜欢的模块的版本1.2.3而package.json反映了这一点，但模块本身是对另一个模块的package.json依赖，而 使用{ {1}} ...所以当你安装时，新的内部依赖项和通配符最终会破坏你认为被“锁定”的模块。
看到了问题？对顶级版本的版本控制进行硬编码，但不强制执行任何操作......如果您依赖的模块作者（或他们依赖的模块）使用通配符，你不能百分百肯定事情将是copacetic。
要严格执行某个版本，您需要使用npm shrinkwrap。 （与文档的链接提供了更多背景知识，如果您的项目使用了多个非常简单的模块，这很好理解。）
现在......你的问题。
你说：
我的意思是，如果有什么事情发生并且npm不可用或者 无法找到特定版本的模块？
根据这个答案的前两部分，现在应该清楚的是，"*"中明确列出了依赖关系并没有什么坏处，因为每次应用程序运行时节点都不会检查事物。 package.json在调用特定操作（安装，更新等）时使用npm，但即便如此，它也是手动触发器。
虽然情况各不相同，但我很少能想象在package.json中省略依赖关系是个好主意。如果您不得不重建项目，那么您将遇到麻烦。如果项目非常好，你想分享它，你就会遇到麻烦。哎呀，如果这是工作的东西，你想去度假，需要在另一台机器上安装......你会遇到麻烦。
因此，初始安装后，依赖项没有负面影响...使用package.json或将依赖项添加到--save。你未来的自我会感谢你。 ：）