この記事では、package.json ファイルと package-lock.json ファイルについて詳しく説明します。お役に立てば幸いです。
フロントエンド開発に関しては、npm が欠かせません。フロントエンド パッケージ管理の責任者である npm は私たちが知っておくべきことです。
あなたは毎日 npm を使用してパッケージをインストールしますが、package.json と package-lock.json という 2 つのファイルについてはよく知っているでしょう。いくら？今日は、皆さんのお役に立てればと思い、これら 2 つのファイルを詳細に分析します。
package.json と package-lock.json について説明する前に、まず npm インストール パッケージ メソッド と について説明しましょう。 npm インストール プロセス 。
npm パッケージのインストール方法はローカルインストールとグローバルインストールに分かれます。 npm install または短縮形 npm i を使用してインストールします。
ローカルにインストールされたパッケージは、現在のディレクトリでのみ使用できます。
ローカル インストールは非常に簡単です。例として element-ui を取り上げます。
npm i element-ui
実際のプロジェクト開発プロセスでは、最初に package.json# を生成します。ローカルインストール用の##ドキュメント。パッケージのバージョンは、インストール中にファイルに自動的に記録されます。
(devDependency) と運用依存関係 (依存関係) に分割されます。
(devDependency) にインストールできます。たとえば、webpack、vite などです。
(依存関係) にインストールできます。たとえば、element-ui などです。
(devDependency) に配置されている場合は、パラメーター --save-dev または -D## を渡します。 ＃それはキャンです。 インストールするパッケージが運用依存関係
に配置されている場合は、パラメーター --save または -S# を渡すことができます。 ## 。 依存関係パラメータを渡さない場合に注意してください。パッケージはデフォルトで運用環境の依存関係にインストールされます
グローバル インストール
--global を渡すことができます。
npm i -g element-ui npm i --global element-ui
npm config get prefix を通じて、グローバルにインストールされたパッケージのパスを表示できます。 
npm 構成情報の検索
.npmrc を確認します。ない場合は、npm の組み込み ## を使用します。 #.npmrc#.## ドキュメント。 依存関係ツリーの構築
の情報が使用されます。依存関係ツリーを生成するために直接使用されます。 依存関係ツリーに従って完全な依存関係リソースをダウンロードする依存関係ツリーを取得したら、依存関係ツリーに従って完全な依存関係リソースをダウンロードできます。ダウンロードする前に、まずキャッシュされたリソースがあるかどうかを確認し、キャッシュされたリソースがある場合は、キャッシュされたリソースを
package-lock.json ファイルの生成
package-lock.json生成メソッドについて説明します。
package.json和package-lock.json生成方式首先要明确一点，package.json不会自动生成，需要我们使用命令创建。package-lock.json是自动生成的，我们使用 npm install 安装包后就会自动生成。
下面我们介绍下怎么创建package.json。
npm 为我们提供了创建 package.json 文件的命令 npm init，执行该命令会问几个基本问题，如包名称、版本号、作者信息、入口文件、仓库地址、关键字、描述、许可协议等，多数问题已经提供了默认值，你可以在问题后敲回车接受默认值。
基本问题问完之后 npm 会在生成文件之前把 package.json 文件内容打出来供你确认，点击enter键就会生成package.json 文件。
如果觉得这样一步一步太慢的话我们还可以一键生成。使用npm init -y 或者 npm init -f就可以一键生成package.json 文件啦。(npm init -y 和 npm init -f是npm init --yes 和 npm init --force的简写形式)。
到这里，小伙伴们肯定有疑问了，一键生成的package.json里面的内容是在哪里控制的呢？比如我想一键生成出来的package.json里面的author是我自己需要怎么做呢？
我们来看看npm的初始配置吧，使用npm config ls -l命令查看npm的所有配置。
可以发现我们的init-author-name的配置是空，所以我们来设置下。
# 设置配置 npm config set init-author-name 'randy' # 查看配置 npm config get init-author-name
我们再来生成一遍package.json
可以发现，我们的author就有默认值啦，其他的默认配置都可以设置，这里笔者就不再举例了。
package.json文件，它是项目的配置文件，常见的配置有配置项目启动、打包命令，声明依赖包等。package.json文件是一个JSON对象，该对象的每一个成员就是当前项目的一项设置。
下面笔者分别介绍各个配置代表的意义。
name很容易理解，就是项目的名称。
version字段表示该项目包的版本号，它是一个字符串。在每次项目改动后，即将发布时，都要同步的去更改项目的版本号。
npm默认所有的Node包都使用语义化版本号，这是一套指导开发人员如何增长版本号的规则。
每个版本号都形如：1.2.3，有三部分组成，依次叫主版本号、次版本号、修订号；
当新版本无法兼容基于前一版本的代码时，则提高主版本号；
当新版本新增了功能和特性，但仍兼容前一版本的代码时，则提高次版本号；
当新版本仅仅修正了漏洞或者增强了效率，仍然兼容前一版本代码，则提高修订号；
默认情况下，npm install xxx --save下载的都是最新版本，并且会在package.json文件里登记一个最优版本号。
举个例子，我们安装element-ui
npm i element-ui -S
在安装的时候它会选择目前的一个最新的版本进行安装，我们查看github，看到element-ui的最新版本是2.15.9。
这里我们自动安装的也就是2.15.9版本，并且版本号并不是固定的而是一个最优版本。
那什么是最优版本呢？
最优版本会在版本前多了一个^符号，这个符号其实是有特殊意义的。同理这个符号还有可能是~符号。
那这两个符号有什么区别呢？
^意味着下载的包可能会是更高的次版本号或者修订版本号。(也就是主版本不能变，次版本、修订版本可以随意变)。
兼容某个大版本 如：^1.1.2 ，表示>=1.1.2 <h4 data-id="heading-19"><strong>~ 兼容某个次版本</strong></h4><p>而<code>~</code>意味着有可能会有更高的修订版本号。(也就是主版本、次版本不能变，修订版本可以随意变)。</p><pre class="brush:php;toolbar:false">兼容某个次版本 如：~1.1.2，表示>=1.1.2 <p>看了上面版本号的指定后，我们可以知道，当我们使用了 <code>^</code> 或者 <code>~</code> 来控制依赖包版本号的时候 ，多人开发，就有可能存在大家安装的依赖包版本不一样的情况，就会存在项目运行的结果不一样。</p><p><strong>举个例子</strong></p><p>假设我们中安装了 <code>vue</code>, 当我们运行安装 <code>npm install vue -save</code> 的时候，在项目中的<code>package.json</code> 的 <code>vue</code> 版本是 <code>vue: ^3.0.0</code>, 我们电脑安装的<code>vue</code>版本就是 <code>3.0.0</code> 版本，我们把项目代码提交后，过了一段时间，vue 发布了新版本 <code>3.1.0</code>，这时新来一个同事，从新 <code>git clone</code> 克隆项目，执行 <code>npm install</code>安装的时候，在他电脑的vue版本就是 <code>3.1.0</code>了，因为^只是锁了主要版本，这样我们电脑中的<code>vue</code>版本就会不一样。<strong>从理论上讲（大家都遵循语义版本控制的话）</strong> ，它们应该仍然是兼容的(因为次版本号的修改只是新功能，并不是不兼容旧版本)，这里假设 <code>vue</code> 次版本的迭代会影响我们正在使用的功能，那么这就会导致严重的问题，我们同一个项目会产生不同的运行结果。</p><p>这时也许有同学想到，那么我们在<code>package.json</code>上面锁死依赖包的版本号不就可以了? 直接写 <code>vue: 3.0.0</code>锁死，这样大家安装<code>vue</code>的版本都是<code>3.0.0</code>版本了。</p><p>这个想法固然是不错的，但是你只能控制你自己的项目锁死版本号，那你项目中依赖包的依赖包呢？你怎么控制限制别人锁死版本号呢？</p><h3 data-id="heading-20"><strong>description</strong></h3><p><code>description</code>字段用来描述这个项目包，它是一个字符串，可以让其他开发者在 npm 的搜索中发现我们的项目包。</p><h3 data-id="heading-21"><strong>author</strong></h3><p><code>author</code>顾名思义就是作者，表示该项目包的作者。</p><h3 data-id="heading-22"><strong>contributors</strong></h3><p><code>contributors</code>表示该项目包的贡献者，和<code>author</code>不同的是，该字段是一个数组，包含所有的贡献者</p><h3 data-id="heading-23"><strong>homepage</strong></h3><p><code>homepage</code>就是项目的主页地址了，它是一个字符串。</p><h3 data-id="heading-24"><strong> repository</strong></h3><p><code>repository</code>表示代码的存放仓库地址</p><h3 data-id="heading-25"><strong> bugs</strong></h3><p><code>bugs</code>表示项目提交问题的地址</p><h3 data-id="heading-26"><strong>依赖类型</strong></h3><p>前面说到有开发依赖和生产依赖，其实npm还有同版本的依赖、捆绑依赖、可选依赖。</p>
dependencies 生产依赖
devDependencies 开发依赖
peerDependencies 同版本的依赖
bundledDependencies 捆绑依赖
optionalDependencies 可选依赖
dependencies 表示项目依赖，这些依赖都会成为你的线上生产环境中的代码组成的部分。当它关联到 npm 包被下载的时候，dependencies下的模块也会作为依赖，一起被下载。
devDependencies表示开发依赖, 不会被自动下载的。因为 devDependencies 一般是用于开发阶段起作用或是只能用于开发环境中被用到的。 比如说我们用到的 Webpack，预处理器 babel-loader、scss-loader，测试工具E2E等， 这些都相当于是辅助的工具包, 无需在生产环境被使用到的。
这里笔者啰嗦一句，当我们只开发应用，不对外开源的话，包随意放在dependencies或devDependencies是不影响的，因为被用到的模块不管你再哪个依赖里面都会被打包。但是如果开发的是库文件，是开源的，已经上传到npm仓库的，这个你就得严格区分dependencies和devDependencies依赖了。因为当你在安装第三方包的时候，只会同步下载第三方包dependencies里面的依赖，所以，当你第三方包的某依赖写到devDependencies中，被别人下载后没下载到该依赖是会报错运行不了的。
peerDependencies 表示同版本的依赖，很多小伙伴肯定难以理解，下面笔者举个例子就明白了。
vuex我们都使用过，vue的状态管理器，它肯定是依赖vue的，但是我们查看它的package.json文件，会发现dependencies并没有依赖vue。
啊！这是怎么回事呢？其实他就是用到了peerDependencies 同版本的依赖。
这下知道什么意思了吧，就是这个包它非常清楚的知道，你使用我的时候必定是在vue环境下使用，所以你一定会安装vue，所以我就没必要再在dependencies下申明vue依赖了，只需要在peerDependencies申明依赖就行了，和主项目共用同一个vue依赖，避免了重复安装。
这样的好处就是node_modules里面不会安装两个vue。减少了node_modules体积的同时大大提高了安装速度。
bundledDependencies和前面的依赖不同它是一个数组，里面定义了捆绑依赖。
"name": "test", "version": "1.0.0", "bundledDependencies": [ "bundleD1", "bundleD2" ]
当我们此时执行 npm pack的时候, 就会生成一个 test-1.0.0.tgz的压缩包, 在该压缩包中还包含了 bundleD1和 bundleD2 两个安装包。
实际使用到这个压缩包的时候，npm install test-1.0.0.tgz 的命令时, bundleD1和 bundleD2 也会被安装的。
这样做的意义是什么呢？
如果bundleD1和bundleD2包在npm上有，能下载到固然没意义。但是当bundleD1和bundleD2是自己临时开发的，并且当前项目又依赖这两个包，并且这两个包在npm上没有，下载不到，这下就有意义了。相当于跟主包一起捆绑发布。
这里需要注意的是: 在 bundledDependencies 中指定的依赖包, 必须先在dependencies 和 devDependencies 声明过, 否则 npm pack 阶段是会报错的。
optionalDependencies表示可选依赖，就是说当你安装对应的依赖项安装失败了, 也不会对整个安装过程有影响的。一般我们很少会用到它, 这里我是不建议大家去使用, 可能会增加项目的不确定性和复杂性。 了解即可。
当我们维护一些旧项目时，可能对npm包的版本或者Node版本有特殊要求，如果不满足条件就可能无法将项目跑起来。为了让项目开箱即用，可以在engines字段中说明具体的版本号：
"engines": {
"node": ">=8.10.3 =6.9.0"
}需要注意，engines只是起一个说明的作用，即使用户安装的版本不符合要求，也不影响依赖包的安装。
关于scripts可以看看笔者前面写的 npm script的那些骚操作，感兴趣的小伙伴可以自行查看。
config字段用来配置scripts运行时的配置参数。
main 字段用来指定加载的入口文件，在 browser 和 Node 环境中都可以使用。如果我们将项目发布为npm包，那么当使用 require 导入npm包时，返回的就是main字段所列出的文件的module.exports 属性。如果不指定该字段，默认是项目根目录下的index.js。如果没找到，就会报错。
browser字段可以定义 npm 包在 browser 环境下的入口文件。如果 npm 包只在 web 端使用，并且严禁在 server 端使用，使用 browser 来定义入口文件。
module字段可以定义 npm 包的 ESM 规范的入口文件，browser 环境和 node 环境均可使用。如果 npm 包导出的是 ESM 规范的包，使用 module 来定义入口文件。
需要注意，*.js 文件是使用 commonJS 规范的语法(require('xxx'))，* .mjs 是用 ESM 规范的语法(import 'xxx')。
上面三个的入口入口文件相关的配置是有差别的，特别是在不同的使用场景下。在Web环境中，如果使用loader加载ESM（ES module），那么这三个配置的加载顺序是browser→module→main，如果使用require加载CommonJS模块，则加载的顺序为main→module→browser。
Webpack在进行项目构建时，有一个target选项，默认为Web，即构建Web应用。如果需要编译一些同构项目，如node项目，则只需将webpack.config.js的target选项设置为node进行构建即可。如果在Node环境中加载CommonJS模块，或者ESM，则只有main字段有效。
bin字段用来指定各个内部命令对应的可执行文件的位置
"bin": { "someTool": "./bin/someTool.js" },
"scripts": {
"dev": "someTool build"
}上面的例子相当于定义了一个命令someTool，它对应的可执行文件的位置是./bin/someTool.js，这样我们就能在scripts里面直接使用该命令了someTool。
files配置是一个数组，用来描述当把npm包作为依赖包安装时需要说明的文件列表。当npm包发布时，files指定的文件会被推送到npm服务器中，如果指定的是文件夹，那么该文件夹下面所有的文件都会被提交。
如果有不想提交的文件，可以在项目根目录中新建一个.npmignore文件，并在其中说明不需要提交的文件，防止垃圾文件推送到npm上。这个文件的形式和.gitignore类似。写在这个文件中的文件即便被写在files属性里也会被排除在外。比如可以在该文件中这样写：
node_modules .vscode build .DS_Store
man 命令是 Linux 中的帮助指令，通过该指令可以查看 Linux 中的指令帮助、配置文件帮助和编程帮助等信息。如果 node.js 模块是一个全局的命令行工具，在 package.json 通过 man 属性可以指定 man 命令查找的文档地址。
man 字段可以指定一个或多个文件, 当执行man {包名}时, 会展现给用户文档内容。
需要注意：
man文件必须以数字结尾，如果经过压缩，还可以使用.gz后缀。这个数字表示文件安装到哪个 man 节中；man 文件名称不是以模块名称开头的，安装的时候会加上模块名称前缀。对于上面的配置，可以使用以下命令来执行查看文档：
man npm-access man npm-audit
directories字段用来规范项目的目录。node.js 模块是基于 CommonJS 模块化规范实现的，需要严格遵循 CommonJS 规范。模块目录下除了必须包含包项目描述文件 package.json 以外，还需要包含以下目录：
在实际的项目目录中，我们可能没有按照这个规范进行命名，那么就可以在directories字段指定每个目录对应的文件路径：
"directories": {
"bin": "./bin",
"lib": "./lib",
"doc": "./doc",
"test" "./test",
"man": "./man"
},这个属性实际上没有什么实际的作用，当然不排除未来会有什么比较有意义的用处。
private字段可以防止我们意外地将私有库发布到npm服务器。只需要将该字段设置为true。
preferGlobal字段表示用户不把该模块安装为全局模块。如果设置为true并把该模块安装为全局模块就会显示警告。
它并不会真正的防止用户进行局部的安装，只是对用户进行提示，防止产生误解。
publishConfig配置会在模块发布时生效，用于设置发布时一些配置项的集合。如果不想模块被默认标记为最新，或者不想发布到公共仓库，可以在这里配置tag或仓库地址。
os字段可以让我们设置该npm包可以在什么操作系统使用，不能再什么操作系统使用。如果我们希望开发的npm包只运行在linux，为了避免出现不必要的异常，建议使用Windows系统的用户不要安装它，这时就可以使用os配置：
"os" ["linux"] // 适用的操作系统 "os" ["!win32"] // 禁用的操作系统
该配置和OS配置类似，用CPU可以更准确的限制用户的安装环境：
"cpu" ["x64", "AMD64"] // 适用的cpu "cpu" ["!arm", "!mips"] // 禁用的cpu
可以看到，黑名单和白名单的区别就是，黑名单在前面加了一个!。
license 字段用于指定软件的开源协议，开源协议表述了其他人获得代码后拥有的权利，可以对代码进行何种操作，何种操作又是被禁止的。常见的协议如下：
typings或者types字段用来指定TypeScript的入口文件
eslint的配置可以写在单独的配置文件.eslintrc.json 中，也可以写在package.json文件的eslintConfig配置项中。
babel的配置可以写在单独的配置文件babel.config.json 中，也可以写在package.json文件的babel配置项中。
使用该字段可以让 npm 上所有的文件都开启 cdn 服务，该CND服务由unpkg提供。
lint-staged是一个在Git暂存文件上运行linters的工具，配置后每次修改一个文件即可给所有文件执行一次lint检查，通常配合gitHooks一起使用。
使用lint-staged时，每次提交代码只会检查当前改动的文件。
gitHooks用来定义一个钩子，在提交（commit）之前执行ESlint检查。在执行lint命令后，会自动修复暂存区的文件。修复之后的文件并不会存储在暂存区，所以需要用git add命令将修复后的文件重新加入暂存区。在执行pre-commit命令之后，如果没有错误，就会执行git commit命令
"gitHooks": {
"pre-commit": "lint-staged"
}这里就是配合lint-staged来进行代码的检查操作。每次commit前运行lint-staged。
browserslist字段用来告知支持哪些浏览器及版本。Babel、postcss、eslint等工具都会用到它。
当然你也可以单独建立.browserslistrc文件来配置。如需了解更多可以查看browserslist 官方文档。
前面说了package.json里面的包版本不是一个具体的版本，而是一个最优版本。而package-lock.json里面定义的是某个包的具体版本，以及包之间的层叠关系。
一个 package-lock.json 里面的每个依赖主要是有以下的几部分组成的:
dependencices 中的依赖项node_modeles 中依赖的包(特殊情况下才存在)。并不是所有的子依赖都有 dependencies 属性,只有子依赖的依赖和当前已安装在根目录的 node_modules 中的依赖冲突之后, 才会有这个属性。 这可能涉及嵌套情况的依赖管理。假设我们的项目依赖A、B、C三个包，并且B包又依赖特定版本的C包，所以B包就会有dependencices，那么我们项目的整个node_modules的目录结构如下
node_modules A.package B.package node_modules C.package C.package
当package.json里面不再使用最优版本，而是一个特定有效版本，也就是版本号前不带修饰符，这样package.json和package-lock.json里面的版本号才是一致的。
或者我们npm install xxx@1.1.2 带上版本号，安装特定版本的包package.json和package-lock.json里面的版本号也是一致的。
或者我们package.json里面定义的包版本就是最新的，我们安装的时候package.json和package-lock.json里面的版本号也会是一致的。
package-lock.json在npm install的时候会自动生成。
当我们修改依赖位置，比如将部分包的位置从 dependencies 移动到 devDependencies 这种操作，虽然包未变，但是也会影响 package-lock.json，会将部分包的 dev 字段设置为 true。
还有如果我们安装源 registry 不同，执行 npm install 时也会修改 package-lock.json。
因为他是会记录我们的依赖包地址的。
当我们使用npm install添加或npm uninstall移除包的时候，同时也会修改 package-lock.json。
当我们更新某个包的版本的时候，同时也会修改 package-lock.json。
我们知道，使用npm install xxx会安装某最新版本的包。
如果在根目录下直接运行npm install，那么npm会根据package.json下载所有的最新版本的包。
那么怎么安装指定版本的包呢？
我们只需要安装的时候带上版本号就可以啦。比如笔者上面element-ui默认安装的最新版本是2.15.9。我们来安装一个2.15.7的特定版本。
npm install element-ui@2.15.7
我们最新版本的2.15.9的版本包就会被替换。并且它会同步修改我们的package.json和package-lock.json。
我们知道，安装完生成package-lock.json之后包的版本就会被固定下来，后续不管你怎么npm install都不会再变化。
如果我想更新到最新版本的包该怎么办呢？
更新包的版本有很多种方式。
我们知道最新包的版本，直接按上面的安装指定包并带上版本号即可。原理和安装特定版本的包一致。
npm install element-ui@2.15.9
它会同步修改我们的package.json和package-lock.json。
不知道最新包的版本，我们运行npm update xxx 即可。
npm update element-ui
它会将指定包更新成最新版本，并且同步修改我们的package.json和package-lock.json。
如果想更新项目下所有的包，直接运行 npm update 即可。
请注意，更新包它是会遵循我们的最优版本号控制的。也就是说当我们的版本是被^修饰时，再怎么更新它只会更新次版本和修订版本，并不会更新主版本。
比如笔者安装的element-ui包的版本是1.0.0
package.json里面版本号如下
当我们npm update element-ui更新包时，它只会更新成最新的次版本和修订版本，并不会更新主版本。
package.json里面版本号如下
package-lock.json如果想更新项目下所有的包我们还可以将package-lock.json删除，然后运行npm install，它也会安装所有的最新版本的包，并且会重新生成package-lock.json。
至于我们要不要提交 lockfiles 到仓库中？这个就需要看我们具体的项目的定位了。
如果是开发一个应用, 我的理解是 package-lock.json文件提交到代码版本仓库.这样可以保证项目中成员、运维部署成员或者是 CI 系统, 在执行 npm install后, 保证在不同的节点能得到完全一致的依赖安装的内容，减少bug的出现。
如果你的目标是开发一个给外部环境用的库，那么就需要认真考虑一下了, 因为库文件一般都是被其他项目依赖的，在不使用 package-lock.json的情况下，就可以复用主项目已经加载过的包，减少依赖重复和体积
如果说我们开发的库依赖了一个精确版本号的模块，那么在我们去提交 lockfiles 到仓库中可能就会出现, 同一个依赖被不同版本都被下载的情况，这样加大了node_modules的体积。如果我们作为一个库的开发者， 其实如果真的使用到某个特定的版本依赖的需求, 那么定义peerDependencies 是一个更好的选择。
所以, 我个人比较推荐的一个做法是:把 package-lock.json一起提交到仓库中去, 不需要 ignore。但是在执行 npm publish 命令的时候,也就是发布一个库的时候, 它其实应该是被忽略的不应该被发布出去的。
在项目中如果没有锁版本的必要，可以不使用package-lock.json，在安装模块时指定--no-lock即可。
我们都知道package-lock.json主要是用来锁定包版本的。
其实在npm的发展历史中，控制包的版本有package-lock.json和npm-shrinkwrap.json两种方式
在npm5之前（不包括5），主要是用npm-shrinkwrap.json来精准控制安装指定版本的npm包。
那怎么生成npm-shrinkwrap.json呢？其实一条命令npm shrinkwrap就能搞定。
它会生成一个npm-shrinkwrap.json文件，记录目前所有依赖包（及更底层依赖包）的版本信息。这样当以后其他人运行npm install命令时，npm首先会找到npm-shrinkwrap.json文件，依照其中的信息准确的安装每一个依赖包，只有当这个文件不存在时，npm才会使用package.json。
因为这是npm5之前的方案，所以现在基本上看不到了。现在都是package-lock.json方案。
相较npm-shrinkwrap.json，package-lock.json的优点是能自动生成。
官方文档是这样解释的：package-lock.json 它会在 npm 更改 node_modules 目录树或者 package.json 时自动生成的 ，它准确的描述了当前项目npm包的依赖树，并且在随后的安装中会根据 package-lock.json 来安装，保证是相同的一个依赖树，不考虑这个过程中是否有某个依赖有小版本的更新。
当我们在一个项目中npm install时候，会自动生成一个package-lock.json文件，和package.json在同一级目录下。package-lock.json记录了项目的一些信息和所依赖的模块。这样在每次安装都会出现相同的结果，不管你在什么机器上面或什么时候安装。
可以看到package-lock.json里面包的版本不再是最优版本啦，而是一个固定版本，这也是它为什么锁定版本的原因。
并且我们依赖的依赖它也会安装一个特定的版本，并锁定起来。比如element-ui所依赖的throttle-debounce
所以当我们下次再npm install时候，npm 发现如果项目中有 package-lock.json 文件，则会根据 package-lock.json 里的内容来处理和安装依赖而不再根据 package.json。
可见package-lock.json原理就是将项目中用到的所有依赖都指定一个固定的版本，后续安装直接读取该文件来安装依赖。
在这里需要注意，如果用的是cnpm是不会自动生成package-lock.json文件的。我们平时开发最好的实践就是使用npm然后将镜像设置为淘宝源就可以了。
// 设置淘宝镜像 npm config set registry https://registry.npm.taobao.org // 查看镜像源 npm config get registry
当我们的项目第一次去搭建的时候, 使用 npm install 安装依赖包, 并去提交 package.json、package-lock.json, 至于node_moduled目录是不用提交的。
当我们作为项目的新成员的时候, checkout/clone项目的时候, 执行一次 npm install 去安装依赖包，它会根据package-lock.json下载对应固定版本的包。
当我们出现了需要升级依赖的需求的时候:
升级小版本的时候, 依靠 npm update
升级大版本的时候, 依靠 npm install xxx
当然我们也有一种方法, 直接去修改 package.json 中的版本号, 并去执行 npm install 去升级版本
当我们本地升级新版本后确认没有问题之后, 去提交新的 package.json 和 package-lock.json文件。
当我们出现了需要降级依赖的需求的时候:
我们去执行npm install @x.x.x 命令后，验证没有问题之后, 是需要提交新的 package.json 和 package-lock.json 文件。
当我们出现了需要删除依赖的需求的时候:
当我们执行 npm uninstall 命令后，需要去验证，提交新的 package.json 和 package-lock.json 文件。
或者是更加暴力一点, 直接操作 package.json, 删除对应的依赖, 执行 npm install 命令, 需要去验证，提交新的package.json 和 package-lock.json 文件。
更新された package.json および package-lock.json をコード リポジトリに送信するときは、チーム メンバーに次のことを通知する必要があります。他のチーム メンバーがコードをプルすると、更新された依存関係により、より使いやすい開発環境が提供され、継続的な開発作業が保証されます。
package-lock.json に競合や問題がある場合は、ローカルの package-lock.json ファイルを削除してから、次のファイルを探すことをお勧めします。リモート エンドの package.json と package-lock.json の間に競合がない場合は、npm install コマンドを再度実行します。
package.json と package-lock.json の詳細な説明については、今日はここまでです。
nodejs チュートリアル を参照してください。
以上がpackage.json と package-lock.json を分析した記事の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
