如果你开发像 Web 服务器之类的程序，那么 lock file 是非常有用的。但是如果将库或 CLI 发布到 npm，则永远不要发布 lock file。因为如果你使用它，则意味着你和你的用户可能在使用不同版本的依赖项。
什么是Lock File？
lock file 描述了整个依赖关系树，它在创建时被解析，包括具有特定版本的嵌套依赖关系。在 npm 名为 package-lock.json ，在 yarn 中名为 yarn.lock。在这两个npm和yarn它们被放置旁边你的package.json。
package-lock.json 的内容应该是这样：
{ "name": "lockfile-demo", "version": "1.0.0", "lockfileVersion": 1, "requires": true, "dependencies": { "ansi-styles": { "version": "3.2.1", "resolved": "https://registry.npmjs.org/ansi-styles/-/ansi-styles-3.2.1.tgz", "integrity": "sha512-VT0ZI6kZRdTh8YyJw3SMbYm/u+NqfsAxEpWO0Pf9sq8/e94WxxOpPKx9FR1FlyCtOVDNOQ+8ntlqFxiRc+r5qA==", "requires": { "color-convert": "^1.9.0" } }, "chalk": { "version": "2.4.2", "resolved": "https://registry.npmjs.org/chalk/-/chalk-2.4.2.tgz", "integrity": "sha512-Mti+f9lpJNcwF4tWV8/OrTTtF1gZi+f8FqlyAdouralcFWFQWF2+NgCHShjkCb+IFBLq9buZwE1xckQU4peSuQ==", "requires": { "ansi-styles": "^3.2.1", "escape-string-regexp": "^1.0.5", "supports-color": "^5.3.0" } } } }
yarn.lock 的格式不同，但也包含类似的信息：
# THIS IS AN AUTOGENERATED FILE. DO NOT EDIT THIS FILE DIRECTLY. # yarn lockfile v1 ansi-styles@^3.2.1: version "3.2.1" resolved "https://registry.yarnpkg.com/ansi-styles/-/ansi-styles-3.2.1.tgz#41fbb20243e50b12be0f04b8dedbf07520ce841d" integrity sha512-VT0ZI6kZRdTh8YyJw3SMbYm/u+NqfsAxEpWO0Pf9sq8/e94WxxOpPKx9FR1FlyCtOVDNOQ+8ntlqFxiRc+r5qA== dependencies: color-convert "^1.9.0" chalk@^2.4.2: version "2.4.2" resolved "https://registry.yarnpkg.com/chalk/-/chalk-2.4.2.tgz#cd42541677a54333cf541a49108c1432b44c9424" integrity sha512-Mti+f9lpJNcwF4tWV8/OrTTtF1gZi+f8FqlyAdouralcFWFQWF2+NgCHShjkCb+IFBLq9buZwE1xckQU4peSuQ== dependencies: ansi-styles "^3.2.1" escape-string-regexp "^1.0.5" supports-color "^5.3.0"
两者都包含一些重要的信息：
安装的每个依赖项的实际版本
每个依赖项的依赖项
已解决的软件包中用校验和验证软件包的完整性
既然 lock file 中已经列出了所有的依赖项，拿为什么还要将它们写在 package.json 中呢？为什么我们需要两个文件？
package.json vs. Lock File
package.json 中 dependencies 字段显示你的项目应该安装的依赖项，但不显示这些依赖项的依赖项。依赖项可以指定精确版本或 semver 范围。对于 semver 范围，npm 或 yarn 将h会选择最适合的版本。
这意味着，如果在发布新版本时多次运行 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，能看到包含所有文件的输出。