这意味着，如果在发布新版本时多次运行 npm install ，有可能会得到相同版本的依赖项。例如用 npm install twilio 安装 twilio 这样的依赖项，那么 package.json 中的依赖项可能会存在类似于这样的条目：
{
"dependencies": {
"twilio": "^3.30.3"
}
}如果你查阅 npm 网站上的 semver 文档，就会看到 ^ 意味着任何大于 3.30.3 的版本和小于 4.0.0 都是有效版本。因此，如果在发布新版本时你没有锁定文件，npm install 或 yarn install 会自动安装一个，你的 package.json 将不会被更新。但是 lock file 的内容会有所不同。
如果 npm 或 yarn 找到它们各自的 lock file，将使用它们代替模块安装。这对于持续集成（CI）等情况尤其有用。对于此这种场景，你可以针对相应的包管理器使用特殊命令或标志：
npm ci # will install exactly what's in the package-lock.json
yarn install --frozen-lock-file # will install exactly what's in yarn.lock without updating it当你在构建 Web 程序或服务器之类的应用时，这非常有用，因为我们希望在 CI 环境中模拟用户的行为。因此，如果在源代码控制（如 git）中跟踪我们的 lock file，就可以确保每个开发人员以及服务器或构建系统还有 CI 系统都能够使用相同版本的依赖项。
那么当我们编写要发布到 npm 的库时，为什么不能做同样的事呢？要回答这个问题，首先要讨论发布的工作原理。
如何发布模块
与某些人想的相反，你发布到 npm 的内容并不总是与 GitHub 上或项目中的内容完全相同。发布模块的方式是 npm 将通过检查 package.json 和 .npmignore 文件中的 files 键或者如果没有“来确定应该发布的文件。 gitignore文件。还有一些文件总是包含在内，有些文件将永远被排除在外。你可以在 [npm page](https://docs.npmjs.com/files/package.json#files) 上找到这些文件的完整列表。例如，.git` 目录始终会被忽略。
之后 npm 将会获取文件列表，并用 npm pack 将它们一起打包成 tarball。如果要查看打包的文件，可以在项目中运行 npm pack –dry-run，能看到包含所有文件的输出。
那个 tarball 将被上传到 npm注册表。运行此命令时你可能会注意到加入你已经有了一个 package-lock.json，它实际上没有被捆绑。这是因为 package-lock.json 将始终被忽略。
这意味着如果另一个开发人员安装了你发布的软件包，他们永远不会下载你的 package-lock.json，因此在安装过程中将会完全忽略它。
这可能会导致“在我的机器上能够工作”的意外，因为你的 CI 和开发环境可能会选择不同的依赖项版本。那么我们可以做些什么呢？
禁用 lock file 并收缩包装
