本篇文章帶大家詳解package.json和package-lock.json文件，希望對(duì)大家有所幫助！

如何快速入門VUE3.0：進(jìn)入學(xué)習(xí)

說到前端開發(fā)，就一定離不開npm，作為前端包管理的老大，npm是我們必須知道的一個(gè)東西。

雖然每天都用npm安裝包，但是你們對(duì)package.json和package-lock.json這兩個(gè)文件又了解多少呢？今天筆者就來詳細(xì)分析下這兩個(gè)文件，希望能對(duì)大家有所幫助。

在說package.json和package-lock.json之前，我們先來說說npm安裝包的方式和npm的安裝流程。

npm 安裝包的方式

npm 安裝包的方式分為本地安裝和全局安裝。安裝使用npm install或簡(jiǎn)寫形式npm i。

本地安裝

本地安裝的包只能在當(dāng)前目錄下使用。

本地安裝很簡(jiǎn)單，以element-ui為例

npm i element-ui

在實(shí)際項(xiàng)目開發(fā)過程中，本地安裝我們都會(huì)先生成package.json文件。然后安裝的時(shí)候包的版本會(huì)自動(dòng)記錄在該文件中。

本地安裝的包又分為開發(fā)依賴(devDependencies)和生產(chǎn)依賴(dependencies)。

對(duì)于一些只會(huì)在開發(fā)環(huán)境中用到的包我們可以安裝在開發(fā)依賴(devDependencies)中。比如webpack、vite等等。

對(duì)于一些會(huì)在生產(chǎn)環(huán)境中用到的包我們可以安裝在生產(chǎn)依賴(dependencies)中。比如element-ui等等。

那么怎么讓安裝的包分別放到對(duì)應(yīng)的依賴位置呢？

如果想要安裝的包放在開發(fā)依賴(devDependencies)中，我們傳遞參數(shù) --save-dev 或 -D 即可。

如果想要安裝的包放在生產(chǎn)依賴(dependencies)中，我們傳遞參數(shù) --save 或 -S 即可。

注意如果我們沒傳遞依賴參數(shù)。會(huì)把包默認(rèn)安裝到生產(chǎn)依賴(dependencies)中

全局安裝

全局安裝的包能在當(dāng)本機(jī)所有目錄下使用。我們?cè)诎惭b包的時(shí)候傳遞參數(shù)-g或--global即可。

npm i -g element-ui  npm i --global element-ui

全局安裝的包路徑我們可以通過npm config get prefix查看。

npm 安裝流程

前面我們只是介紹了 npm install 是用來安裝依賴的，下面再講一下它到底是怎么安裝的以及一些具體的安裝細(xì)節(jié)。

查找 npm 的配置信息

執(zhí)行安裝命令之后，npm 首先會(huì)去查找 npm 的配置信息。 其中，我們最熟悉的就是安裝時(shí)候的源信息。npm 會(huì)在項(xiàng)目中查找是否有 .npmrc 文件，沒有的話會(huì)再檢查全局配置的 .npmrc ，還沒有的話就會(huì)使用 npm 內(nèi)置的 .npmrc 文件。

構(gòu)建依賴樹

獲取完配置文件之后，就會(huì)構(gòu)建依賴樹。首先會(huì)檢查下項(xiàng)目中是否有 package-lock.json ?文件：存在 lock 文件的話，會(huì)判斷 lock 文件和 package.json 中使用的依賴版本是否一致，如果一致的話就使用 lock 中的信息，反之就會(huì)使用 npm 中的信息；那如果沒有 lock 文件的話，就會(huì)直接使用 package.json 中的信息生成依賴樹。

根據(jù)依賴樹下載完整的依賴資源

在有了依賴樹之后，就可以根據(jù)依賴樹下載完整的依賴資源。在下載之前，會(huì)先檢查下是否有緩存資源，如果存在緩存資源的話，那么直接將緩存資源解壓到 node_modules 中。如果沒有緩存資源，那么會(huì)先將 npm 遠(yuǎn)程倉庫中的包下載至本地，然后會(huì)進(jìn)行包的完整性校驗(yàn)，校驗(yàn)通過后將其添加的緩存中并解壓到 node_modules 中。

生成 package-lock.json 文件

生成 package-lock.json 文件。 這個(gè)文件主要是用來鎖定包的版本，這個(gè)筆者后面會(huì)詳細(xì)說。

接下來我們說說 package.json和package-lock.json生成方式

package.json和package-lock.json生成方式

首先要明確一點(diǎn)，package.json不會(huì)自動(dòng)生成，需要我們使用命令創(chuàng)建。package-lock.json是自動(dòng)生成的，我們使用 npm install 安裝包后就會(huì)自動(dòng)生成。

下面我們介紹下怎么創(chuàng)建package.json。

npm 為我們提供了創(chuàng)建 package.json 文件的命令 npm init，執(zhí)行該命令會(huì)問幾個(gè)基本問題，如包名稱、版本號(hào)、作者信息、入口文件、倉庫地址、關(guān)鍵字、描述、許可協(xié)議等，多數(shù)問題已經(jīng)提供了默認(rèn)值，你可以在問題后敲回車接受默認(rèn)值。

基本問題問完之后 npm 會(huì)在生成文件之前把 package.json 文件內(nèi)容打出來供你確認(rèn)，點(diǎn)擊enter鍵就會(huì)生成package.json 文件。

如果覺得這樣一步一步太慢的話我們還可以一鍵生成。使用npm init -y 或者 npm init -f就可以一鍵生成package.json 文件啦。(npm init -y 和 npm init -f是npm init --yes 和 npm init --force的簡(jiǎn)寫形式)。

到這里，小伙伴們肯定有疑問了，一鍵生成的package.json里面的內(nèi)容是在哪里控制的呢？比如我想一鍵生成出來的package.json里面的author是我自己需要怎么做呢？

我們來看看npm的初始配置吧，使用npm config ls -l命令查看npm的所有配置。

可以發(fā)現(xiàn)我們的init-author-name的配置是空，所以我們來設(shè)置下。

# 設(shè)置配置 npm config set init-author-name 'randy'  # 查看配置 npm config get init-author-name

我們?cè)賮砩梢槐?code>package.json

可以發(fā)現(xiàn)，我們的author就有默認(rèn)值啦，其他的默認(rèn)配置都可以設(shè)置，這里筆者就不再舉例了。

package.json詳解

package.json文件，它是項(xiàng)目的配置文件，常見的配置有配置項(xiàng)目啟動(dòng)、打包命令，聲明依賴包等。package.json文件是一個(gè)JSON對(duì)象，該對(duì)象的每一個(gè)成員就是當(dāng)前項(xiàng)目的一項(xiàng)設(shè)置。

下面筆者分別介紹各個(gè)配置代表的意義。

name

name很容易理解，就是項(xiàng)目的名稱。

version

version字段表示該項(xiàng)目包的版本號(hào)，它是一個(gè)字符串。在每次項(xiàng)目改動(dòng)后，即將發(fā)布時(shí)，都要同步的去更改項(xiàng)目的版本號(hào)。

npm依賴包版本號(hào)

npm默認(rèn)所有的Node包都使用語義化版本號(hào)，這是一套指導(dǎo)開發(fā)人員如何增長(zhǎng)版本號(hào)的規(guī)則。

每個(gè)版本號(hào)都形如：1.2.3，有三部分組成，依次叫主版本號(hào)、次版本號(hào)、修訂號(hào)；

• 主版本號(hào)

  當(dāng)新版本無法兼容基于前一版本的代碼時(shí)，則提高主版本號(hào)；

• 次版本號(hào)

  當(dāng)新版本新增了功能和特性，但仍兼容前一版本的代碼時(shí)，則提高次版本號(hào)；

• 修訂號(hào)

  當(dāng)新版本僅僅修正了漏洞或者增強(qiáng)了效率，仍然兼容前一版本代碼，則提高修訂號(hào)；

• 最優(yōu)版本

  默認(rèn)情況下，npm install xxx --save下載的都是最新版本，并且會(huì)在package.json文件里登記一個(gè)最優(yōu)版本號(hào)。

舉個(gè)例子，我們安裝element-ui

npm i element-ui -S

在安裝的時(shí)候它會(huì)選擇目前的一個(gè)最新的版本進(jìn)行安裝，我們查看github，看到element-ui的最新版本是2.15.9。

這里我們自動(dòng)安裝的也就是2.15.9版本，并且版本號(hào)并不是固定的而是一個(gè)最優(yōu)版本。

那什么是最優(yōu)版本呢？

最優(yōu)版本會(huì)在版本前多了一個(gè)^符號(hào)，這個(gè)符號(hào)其實(shí)是有特殊意義的。同理這個(gè)符號(hào)還有可能是~符號(hào)。

那這兩個(gè)符號(hào)有什么區(qū)別呢？

^ 兼容某個(gè)大版本

^意味著下載的包可能會(huì)是更高的次版本號(hào)或者修訂版本號(hào)。(也就是主版本不能變，次版本、修訂版本可以隨意變)。

兼容某個(gè)大版本  如：^1.1.2 ，表示>=1.1.2 <2.0.0，可以是1.1.2，1.1.3，.....，1.1.n，1.2.n，.....，1.n.n

~ 兼容某個(gè)次版本

而~意味著有可能會(huì)有更高的修訂版本號(hào)。(也就是主版本、次版本不能變，修訂版本可以隨意變)。

兼容某個(gè)次版本   如：~1.1.2，表示>=1.1.2 <1.2.0，可以是1.1.2，1.1.3，1.1.4，.....，1.1.n

看了上面版本號(hào)的指定后，我們可以知道，當(dāng)我們使用了 ^ 或者 ~ 來控制依賴包版本號(hào)的時(shí)候 ，多人開發(fā)，就有可能存在大家安裝的依賴包版本不一樣的情況，就會(huì)存在項(xiàng)目運(yùn)行的結(jié)果不一樣。

舉個(gè)例子

假設(shè)我們中安裝了 vue, 當(dāng)我們運(yùn)行安裝 npm install vue -save 的時(shí)候，在項(xiàng)目中的package.json 的 vue 版本是 vue: ^3.0.0, 我們電腦安裝的vue版本就是 3.0.0 版本，我們把項(xiàng)目代碼提交后，過了一段時(shí)間，vue 發(fā)布了新版本 3.1.0，這時(shí)新來一個(gè)同事，從新 git clone 克隆項(xiàng)目，執(zhí)行 npm install安裝的時(shí)候，在他電腦的vue版本就是 3.1.0了，因?yàn)閊只是鎖了主要版本，這樣我們電腦中的vue版本就會(huì)不一樣。從理論上講（大家都遵循語義版本控制的話） ，它們應(yīng)該仍然是兼容的(因?yàn)榇伟姹咎?hào)的修改只是新功能，并不是不兼容舊版本)，這里假設(shè) vue 次版本的迭代會(huì)影響我們正在使用的功能，那么這就會(huì)導(dǎo)致嚴(yán)重的問題，我們同一個(gè)項(xiàng)目會(huì)產(chǎn)生不同的運(yùn)行結(jié)果。

這時(shí)也許有同學(xué)想到，那么我們?cè)?code>package.json上面鎖死依賴包的版本號(hào)不就可以了? 直接寫 vue: 3.0.0鎖死，這樣大家安裝vue的版本都是3.0.0版本了。

這個(gè)想法固然是不錯(cuò)的，但是你只能控制你自己的項(xiàng)目鎖死版本號(hào)，那你項(xiàng)目中依賴包的依賴包呢？你怎么控制限制別人鎖死版本號(hào)呢？

description

description字段用來描述這個(gè)項(xiàng)目包，它是一個(gè)字符串，可以讓其他開發(fā)者在 npm 的搜索中發(fā)現(xiàn)我們的項(xiàng)目包。

author

author顧名思義就是作者，表示該項(xiàng)目包的作者。

contributors

contributors表示該項(xiàng)目包的貢獻(xiàn)者，和author不同的是，該字段是一個(gè)數(shù)組，包含所有的貢獻(xiàn)者

homepage

homepage就是項(xiàng)目的主頁地址了，它是一個(gè)字符串。

repository

repository表示代碼的存放倉庫地址

bugs

bugs表示項(xiàng)目提交問題的地址

依賴類型

前面說到有開發(fā)依賴和生產(chǎn)依賴，其實(shí)npm還有同版本的依賴、捆綁依賴、可選依賴。

• dependencies 生產(chǎn)依賴

• devDependencies 開發(fā)依賴

• peerDependencies 同版本的依賴

• bundledDependencies 捆綁依賴

• optionalDependencies 可選依賴

dependencies 生產(chǎn)依賴

dependencies 表示項(xiàng)目依賴，這些依賴都會(huì)成為你的線上生產(chǎn)環(huán)境中的代碼組成的部分。當(dāng)它關(guān)聯(lián)到 npm 包被下載的時(shí)候，dependencies下的模塊也會(huì)作為依賴，一起被下載。

devDependencies 開發(fā)依賴

devDependencies表示開發(fā)依賴, 不會(huì)被自動(dòng)下載的。因?yàn)?devDependencies 一般是用于開發(fā)階段起作用或是只能用于開發(fā)環(huán)境中被用到的。 比如說我們用到的 Webpack，預(yù)處理器 babel-loader、scss-loader，測(cè)試工具E2E等， 這些都相當(dāng)于是輔助的工具包, 無需在生產(chǎn)環(huán)境被使用到的。

這里筆者啰嗦一句，當(dāng)我們只開發(fā)應(yīng)用，不對(duì)外開源的話，包隨意放在dependencies或devDependencies是不影響的，因?yàn)楸挥玫降哪K不管你再哪個(gè)依賴?yán)锩娑紩?huì)被打包。但是如果開發(fā)的是庫文件，是開源的，已經(jīng)上傳到npm倉庫的，這個(gè)你就得嚴(yán)格區(qū)分dependencies和devDependencies依賴了。因?yàn)楫?dāng)你在安裝第三方包的時(shí)候，只會(huì)同步下載第三方包dependencies里面的依賴，所以，當(dāng)你第三方包的某依賴寫到devDependencies中，被別人下載后沒下載到該依賴是會(huì)報(bào)錯(cuò)運(yùn)行不了的。

peerDependencies 同版本的依賴

peerDependencies 表示同版本的依賴，很多小伙伴肯定難以理解，下面筆者舉個(gè)例子就明白了。

vuex我們都使用過，vue的狀態(tài)管理器，它肯定是依賴vue的，但是我們查看它的package.json文件，會(huì)發(fā)現(xiàn)dependencies并沒有依賴vue。

啊！這是怎么回事呢？其實(shí)他就是用到了peerDependencies 同版本的依賴。

這下知道什么意思了吧，就是這個(gè)包它非常清楚的知道，你使用我的時(shí)候必定是在vue環(huán)境下使用，所以你一定會(huì)安裝vue，所以我就沒必要再在dependencies下申明vue依賴了，只需要在peerDependencies申明依賴就行了，和主項(xiàng)目共用同一個(gè)vue依賴，避免了重復(fù)安裝。

這樣的好處就是node_modules里面不會(huì)安裝兩個(gè)vue。減少了node_modules體積的同時(shí)大大提高了安裝速度。

bundledDependencies 捆綁依賴

bundledDependencies和前面的依賴不同它是一個(gè)數(shù)組，里面定義了捆綁依賴。

"name": "test", "version": "1.0.0", "bundledDependencies": [ "bundleD1", "bundleD2" ]

當(dāng)我們此時(shí)執(zhí)行 npm pack的時(shí)候, 就會(huì)生成一個(gè) test-1.0.0.tgz的壓縮包, 在該壓縮包中還包含了 bundleD1和 bundleD2 兩個(gè)安裝包。

實(shí)際使用到這個(gè)壓縮包的時(shí)候，npm install test-1.0.0.tgz 的命令時(shí), bundleD1和 bundleD2 也會(huì)被安裝的。

這樣做的意義是什么呢？

如果bundleD1和bundleD2包在npm上有，能下載到固然沒意義。但是當(dāng)bundleD1和bundleD2是自己臨時(shí)開發(fā)的，并且當(dāng)前項(xiàng)目又依賴這兩個(gè)包，并且這兩個(gè)包在npm上沒有，下載不到，這下就有意義了。相當(dāng)于跟主包一起捆綁發(fā)布。

這里需要注意的是: 在 bundledDependencies 中指定的依賴包, 必須先在dependencies 和 devDependencies 聲明過, 否則 npm pack 階段是會(huì)報(bào)錯(cuò)的。

optionalDependencies 可選依賴

optionalDependencies表示可選依賴，就是說當(dāng)你安裝對(duì)應(yīng)的依賴項(xiàng)安裝失敗了, 也不會(huì)對(duì)整個(gè)安裝過程有影響的。一般我們很少會(huì)用到它, 這里我是不建議大家去使用, 可能會(huì)增加項(xiàng)目的不確定性和復(fù)雜性。 了解即可。

engines

當(dāng)我們維護(hù)一些舊項(xiàng)目時(shí)，可能對(duì)npm包的版本或者Node版本有特殊要求，如果不滿足條件就可能無法將項(xiàng)目跑起來。為了讓項(xiàng)目開箱即用，可以在engines字段中說明具體的版本號(hào)：

"engines": {   "node": ">=8.10.3 <12.13.0",   "npm": ">=6.9.0" }

需要注意，engines只是起一個(gè)說明的作用，即使用戶安裝的版本不符合要求，也不影響依賴包的安裝。

scripts

關(guān)于scripts可以看看筆者前面寫的 npm script的那些騷操作，感興趣的小伙伴可以自行查看。

config

config字段用來配置scripts運(yùn)行時(shí)的配置參數(shù)。

main

main 字段用來指定加載的入口文件，在 browser 和 Node 環(huán)境中都可以使用。如果我們將項(xiàng)目發(fā)布為npm包，那么當(dāng)使用 require 導(dǎo)入npm包時(shí)，返回的就是main字段所列出的文件的module.exports 屬性。如果不指定該字段，默認(rèn)是項(xiàng)目根目錄下的index.js。如果沒找到，就會(huì)報(bào)錯(cuò)。

browser

browser字段可以定義 npm 包在 browser 環(huán)境下的入口文件。如果 npm 包只在 web 端使用，并且嚴(yán)禁在 server 端使用，使用 browser 來定義入口文件。

module

module字段可以定義 npm 包的 ESM 規(guī)范的入口文件，browser 環(huán)境和 node 環(huán)境均可使用。如果 npm 包導(dǎo)出的是 ESM 規(guī)范的包，使用 module 來定義入口文件。

需要注意，*.js 文件是使用 commonJS 規(guī)范的語法(require('xxx'))，* .mjs 是用 ESM 規(guī)范的語法(import 'xxx')。

上面三個(gè)的入口入口文件相關(guān)的配置是有差別的，特別是在不同的使用場(chǎng)景下。在Web環(huán)境中，如果使用loader加載ESM（ES module），那么這三個(gè)配置的加載順序是browser→module→main，如果使用require加載CommonJS模塊，則加載的順序?yàn)?code>main→module→browser。

Webpack在進(jìn)行項(xiàng)目構(gòu)建時(shí)，有一個(gè)target選項(xiàng)，默認(rèn)為Web，即構(gòu)建Web應(yīng)用。如果需要編譯一些同構(gòu)項(xiàng)目，如node項(xiàng)目，則只需將webpack.config.js的target選項(xiàng)設(shè)置為node進(jìn)行構(gòu)建即可。如果在Node環(huán)境中加載CommonJS模塊，或者ESM，則只有main字段有效。

bin

bin字段用來指定各個(gè)內(nèi)部命令對(duì)應(yīng)的可執(zhí)行文件的位置

"bin": { "someTool": "./bin/someTool.js" }, "scripts": {   "dev": "someTool build" }

上面的例子相當(dāng)于定義了一個(gè)命令someTool，它對(duì)應(yīng)的可執(zhí)行文件的位置是./bin/someTool.js，這樣我們就能在scripts里面直接使用該命令了someTool。

files

files配置是一個(gè)數(shù)組，用來描述當(dāng)把npm包作為依賴包安裝時(shí)需要說明的文件列表。當(dāng)npm包發(fā)布時(shí)，files指定的文件會(huì)被推送到npm服務(wù)器中，如果指定的是文件夾，那么該文件夾下面所有的文件都會(huì)被提交。

如果有不想提交的文件，可以在項(xiàng)目根目錄中新建一個(gè).npmignore文件，并在其中說明不需要提交的文件，防止垃圾文件推送到npm上。這個(gè)文件的形式和.gitignore類似。寫在這個(gè)文件中的文件即便被寫在files屬性里也會(huì)被排除在外。比如可以在該文件中這樣寫：

node_modules  .vscode  build  .DS_Store

man

man 命令是 Linux 中的幫助指令，通過該指令可以查看 Linux 中的指令幫助、配置文件幫助和編程幫助等信息。如果 node.js 模塊是一個(gè)全局的命令行工具，在 package.json 通過 man 屬性可以指定 man 命令查找的文檔地址。

man 字段可以指定一個(gè)或多個(gè)文件, 當(dāng)執(zhí)行man {包名}時(shí), 會(huì)展現(xiàn)給用戶文檔內(nèi)容。

需要注意：

• man文件必須以數(shù)字結(jié)尾，如果經(jīng)過壓縮，還可以使用.gz后綴。這個(gè)數(shù)字表示文件安裝到哪個(gè) man 節(jié)中；
• 如果 man 文件名稱不是以模塊名稱開頭的，安裝的時(shí)候會(huì)加上模塊名稱前綴。

對(duì)于上面的配置，可以使用以下命令來執(zhí)行查看文檔：

man npm-access man npm-audit

directories

directories字段用來規(guī)范項(xiàng)目的目錄。node.js 模塊是基于 CommonJS 模塊化規(guī)范實(shí)現(xiàn)的，需要嚴(yán)格遵循 CommonJS 規(guī)范。模塊目錄下除了必須包含包項(xiàng)目描述文件 package.json 以外，還需要包含以下目錄：

• bin ：存放可執(zhí)行二進(jìn)制文件的目錄
• lib ：存放js代碼的目錄
• doc ：存放文檔的目錄
• test ：存放單元測(cè)試用例代碼的目錄
• …

在實(shí)際的項(xiàng)目目錄中，我們可能沒有按照這個(gè)規(guī)范進(jìn)行命名，那么就可以在directories字段指定每個(gè)目錄對(duì)應(yīng)的文件路徑：

"directories": {     "bin": "./bin",     "lib": "./lib",     "doc": "./doc",     "test" "./test",     "man": "./man" },

這個(gè)屬性實(shí)際上沒有什么實(shí)際的作用，當(dāng)然不排除未來會(huì)有什么比較有意義的用處。

private

private字段可以防止我們意外地將私有庫發(fā)布到npm服務(wù)器。只需要將該字段設(shè)置為true。

preferGlobal

preferGlobal字段表示用戶不把該模塊安裝為全局模塊。如果設(shè)置為true并把該模塊安裝為全局模塊就會(huì)顯示警告。

它并不會(huì)真正的防止用戶進(jìn)行局部的安裝，只是對(duì)用戶進(jìn)行提示，防止產(chǎn)生誤解。

publishConfig

publishConfig配置會(huì)在模塊發(fā)布時(shí)生效，用于設(shè)置發(fā)布時(shí)一些配置項(xiàng)的集合。如果不想模塊被默認(rèn)標(biāo)記為最新，或者不想發(fā)布到公共倉庫，可以在這里配置tag或倉庫地址。

os

os字段可以讓我們?cè)O(shè)置該npm包可以在什么操作系統(tǒng)使用，不能再什么操作系統(tǒng)使用。如果我們希望開發(fā)的npm包只運(yùn)行在linux，為了避免出現(xiàn)不必要的異常，建議使用Windows系統(tǒng)的用戶不要安裝它，這時(shí)就可以使用os配置：

"os" ["linux"]   // 適用的操作系統(tǒng) "os" ["!win32"]  // 禁用的操作系統(tǒng)

cpu

該配置和OS配置類似，用CPU可以更準(zhǔn)確的限制用戶的安裝環(huán)境：

"cpu" ["x64", "AMD64"]   // 適用的cpu "cpu" ["!arm", "!mips"]  // 禁用的cpu

可以看到，黑名單和白名單的區(qū)別就是，黑名單在前面加了一個(gè)!。

license

license 字段用于指定軟件的開源協(xié)議，開源協(xié)議表述了其他人獲得代碼后擁有的權(quán)利，可以對(duì)代碼進(jìn)行何種操作，何種操作又是被禁止的。常見的協(xié)議如下：

• MIT ：只要用戶在項(xiàng)目副本中包含了版權(quán)聲明和許可聲明，他們就可以拿你的代碼做任何想做的事情，你也無需承擔(dān)任何責(zé)任。
• Apache ：類似于 MIT ，同時(shí)還包含了貢獻(xiàn)者向用戶提供專利授權(quán)相關(guān)的條款。
• GPL ：修改項(xiàng)目代碼的用戶再次分發(fā)源碼或二進(jìn)制代碼時(shí)，必須公布他的相關(guān)修改。

typings或者types

typings或者types字段用來指定TypeScript的入口文件

eslintConfig

eslint的配置可以寫在單獨(dú)的配置文件.eslintrc.json 中，也可以寫在package.json文件的eslintConfig配置項(xiàng)中。

babel

babel的配置可以寫在單獨(dú)的配置文件babel.config.json 中，也可以寫在package.json文件的babel配置項(xiàng)中。

unpkg

使用該字段可以讓 npm 上所有的文件都開啟 cdn 服務(wù)，該CND服務(wù)由unpkg提供。

lint-staged

lint-staged是一個(gè)在Git暫存文件上運(yùn)行linters的工具，配置后每次修改一個(gè)文件即可給所有文件執(zhí)行一次lint檢查，通常配合gitHooks一起使用。

使用lint-staged時(shí)，每次提交代碼只會(huì)檢查當(dāng)前改動(dòng)的文件。

gitHooks

gitHooks用來定義一個(gè)鉤子，在提交（commit）之前執(zhí)行ESlint檢查。在執(zhí)行lint命令后，會(huì)自動(dòng)修復(fù)暫存區(qū)的文件。修復(fù)之后的文件并不會(huì)存儲(chǔ)在暫存區(qū)，所以需要用git add命令將修復(fù)后的文件重新加入暫存區(qū)。在執(zhí)行pre-commit命令之后，如果沒有錯(cuò)誤，就會(huì)執(zhí)行git commit命令

"gitHooks": {   "pre-commit": "lint-staged" }

這里就是配合lint-staged來進(jìn)行代碼的檢查操作。每次commit前運(yùn)行lint-staged。

browserslist

browserslist字段用來告知支持哪些瀏覽器及版本。Babel、postcss、eslint等工具都會(huì)用到它。

當(dāng)然你也可以單獨(dú)建立.browserslistrc文件來配置。如需了解