Npm 新产品管理“；“已解决”-package-lock.json中的字段随着JFrog artifactory不断变化

我们有一个私有的JFrog工件（下面匿名的名称），npm在项目根.npmrc-文件中配置：

registry=https://artifactory.jfrog.private.com:443/api/npm/npm-registry-virtual/

开发者之间通过Git共享的package-lock.json文件中的已解析字段在“npm install”运行期间不断变化，而对package.json没有任何变化

有时会将dl查询参数（指向完全相同的URL）添加到解析的URL中：

- "resolved": "https://artifactory.jfrog.private.com:443/api/npm/npm-registry-virtual/@sailshq/lodash/-/lodash-3.10.3.tgz",
+ "resolved": "https://artifactory.jfrog.private.com:443/api/npm/npm-registry-virtual/@sailshq/lodash/-/lodash-3.10.3.tgz?dl=https://artifactory.jfrog.private.com/@sailshq/lodash/-/lodash-3.10.3.tgz",

有时查询参数指向npmjs.org注册表：

 - "resolved": "https://artifactory.jfrog.private.com:443/api/npm/npm-registry-virtual/aproba/-/aproba-1.2.0.tgz",
 - "resolved": "https://artifactory.jfrog.private.com:443/api/npm/npm-registry-virtual/aproba/-/aproba-1.2.0.tgz?dl=https://registry.npmjs.org/aproba/-/aproba-1.2.0.tgz",

有时该字段直接指向npmjs.org存储库：

- "resolved": "https://artifactory.jfrog.private.com:443/api/npm/npm-registry-virtual/acorn/-/acorn-3.3.0.tgz",
+ "resolved": "https://registry.npmjs.org/acorn/-/acorn-3.3.0.tgz",

这些变化中的任何一个也可能走向相反的方向

这真是令人恼火，因为这意味着我们在package-lock.json中不断地进行无意义的更改，这会导致合并冲突，并且常常会阻止npm ci正确执行。npm缓存清理——强制似乎没有帮助。我知道npm install可以自动解决package-lock.json合并冲突，但这对npm ci没有帮助（因为关键是不要在ci环境中运行npm install）。而且，不管怎样，看到虚拟npm注册表如何在内部解析包有什么好处（我怀疑这里正在发生这种情况）

是否有某种配置选项可以防止JFrog Artifactory对虚拟npm注册表中解析的包URL进行此类更改？或者它可能是npm中的一个bug

环境：

• npm 6.11.3
• JFrog人工制品厂6.10.6

---

这种情况通常是由安装了稍微不同版本的npm的开发人员造成的。npm的第7版刚刚发布，所以现在是确保团队都安装了完全相同的版本的最佳时机

---

如果这不起作用，请尝试将团队切换到或。
我不知道为什么会出现这些备选URL，或者如何使它们停止。但是您可以通过使用减少（甚至消除！）开发人员的合并冲突痛苦。它是由一位在npm cli团队工作多年的开发人员编写的，其唯一目的是自动消除

package lock.json

合并冲突。
我们的团队已经成功地首先运行，以确保本地拉取和缓存的依赖项与

package lock.json

文件匹配

---

然后，进一步的

npm安装

s应该按照预期解决。
我看不到Artifactory可以通过什么方式更改package-lock.json文件。根据npm文档：对于npm修改节点_模块树或package.json的任何操作，都会自动生成package-lock.json。我相信这种行为与npm客户端有关，似乎是同一个问题，因为这些设置可能与更改package-lock.json中的解析字段有关？它应该影响package-lock.json，因为更改是在npm客户端意识到原始URL之前在Artifactory内部完成的。然而，这是值得检查的further@VilleHeikkilä你有没有想过如何保持注册表的一致性？这不是我的经验；相同版本的NPM在不同的机器上产生了不同的解析字段。我们切换到

pnpm

，但仍然存在此问题！只是搅动在

pnpm lock.yaml

文件中。遗憾的是没有得到任何评论，因为建议的解决方案正好解决了OP遇到的问题。没错，他们在问为什么会出现这些URL，我不知道答案（可能需要一位现任或前任JFrog员工以任何权威来回答）。但该软件包解决了这个问题导致的合并难题，而且没有足够的人知道它。