是否应提交npm 5创建的package-lock.json文件
是否应提交npm 5创建的package-lock.json文件
技术背景
在使用npm 5及以上版本时，会自动生成package-lock.json文件。这个文件记录了node_modules树的确切结构，确保后续安装能够生成相同的依赖树，无论中间依赖是否有更新。然而，对于是否应该将package-lock.json文件提交到源代码控制中，开发者们存在不同的看法。
实现步骤
提交package-lock.json文件
- 常规操作：当你使用
npm install或其他修改node_modules树或package.json的操作时，package-lock.json会自动更新。你只需要像提交其他代码文件一样，将其添加到版本控制中。
1 | |
- 使用
npm ci：在持续集成（CI）环境和本地开发环境中，建议使用npm ci代替npm install。npm ci要求存在package-lock.json文件，并且只会使用锁文件中指定的版本进行安装。
1 | |
不提交package-lock.json文件
如果你决定不提交package-lock.json文件，可以在.gitignore文件中添加以下内容：
1 | |
核心代码
使用npm ci安装依赖
1 | |
忽略package-lock.json文件的git diff
1 | |
设置全局禁用package-lock.json
1 | |
最佳实践
应该提交的情况
- 向项目中添加新的
npm或yarn包时。 package.json的任何更改导致.lock文件更新时。- 包、Node.js或
yarn的版本更改导致.lock文件更新时。
不应该提交的情况
- 没有进行编码工作，但
.lock文件更新了，这可能意味着其他开发者在上述应该提交的情况下没有提交他们的锁文件。 - 刚刚拉取代码后，
.lock文件更新了。 - 刚刚克隆代码库后，
.lock文件更新了。 - 编写了一个功能代码，没有涉及上述应该提交的情况，但
.lock文件仍然更新了。
常见问题
“没有意义”
这是一种“无知论证”的逻辑谬误，认为自己不知道原因就认为没有原因。实际上，package-lock.json可以保证不同环境下依赖安装的一致性。
“它是自动生成的”
虽然package-lock.json是自动生成的，但它不是从package.json确定性生成的，因为它受时间和npm注册表中包状态的影响。它是一个快照，用于保证稳定性。
“它会导致合并冲突”
从[email protected]开始，可以通过手动修复package.json的冲突，然后再次运行npm install [--package-lock-only]来解决这些冲突。yarn和pnpm也可以自动解决锁文件的合并冲突。
“合并冲突会干扰PR和MR”
虽然Git提供商不会自动解决锁文件冲突，但锁文件通常不会频繁更改，只有在package.json依赖项更改或开发者手动更改文件时才会改变。
“它会产生大量的diff噪音”
这是一个工具问题，许多工具可以优雅地处理，如自动最小化、分页或虚拟滚动。也可以使用git diff -- . ':(exclude)yarn.lock'或在.gitattributes中将文件标记为二进制来避免看到锁文件的diff。
“精确版本就足够了”
即使在package.json中指定了精确版本，依赖项的依赖项可能仍然使用范围版本，因此无法锁定整个依赖树。
“应用程序使用锁文件，库不使用锁文件”
这种观点是错误的。即使不提交锁文件，它仍然存在于本地机器上锁定依赖项。如果库维护者希望持续测试兼容性，可以在安装和构建库之前删除锁文件。
“不同系统生成的锁文件不同”
如果不同操作系统生成不同的锁文件内容，这可能是一个bug。不同版本的npm可能会产生不同的锁文件输出，但为了稳定性，这是一个小代价。可以使用nvm等工具切换npm版本来解决。
“锁文件可能存在安全风险”
公共项目中的锁文件可能会收到恶意PR，其中的锁文件内容可能会在拉取和安装分支时危及维护者的机器。可以使用lockfile-lint、npm ci或yarn --immutable等CI检查来防范，也可以在本地npmrc中设置ignore-scripts。
综上所述，通常建议将package-lock.json文件提交到源代码控制中，以确保项目在不同环境和开发者之间的依赖一致性。