全方位解讀 package.json

前言

平常在工作中，對package.json這個文件的接觸非常非常少。

• 一些同學可能還會看一下script里面有什么命令，執(zhí)行了哪些方法。
• 又或者了解一下dependencies和devDependencies
• 其他大部分的同學可能直接就npm i和npm start就開始工作了。
• 但是package.json的魅力遠不止如此
• 今天就和我一起探索一下這個項目中不可或缺的——package.json吧！

由淺入深-核心內(nèi)容

準備工作

手摸手新建一個空的package.json

1. npm init
2. 上萬個回車

或者直接執(zhí)行

1. npm init -y
2. 其意思就是全部都略過，和我們上面的無數(shù)個回車的效果一樣

先看看上面有的東西。

{
??"name":?"package.json",?#?項目名稱
??"version":?"1.0.0", #?項目版本（格式：大版本.次要版本.小版本）
??"description":?"",?#?項目描述
??"main":?"index.js",?#?入口文件
??"scripts":?{?#?指定運行腳本命令的?npm?命令行縮寫
????"test":?"echo?\"Error:?no?test?specified\"?&&?exit?1"
??},
??"keywords":?[],?#?關(guān)鍵詞
??"author":?"",?#?作者
??"license":?"ISC"?#?許可證
}

scripts（快捷腳本）

• scripts?字段是?package.json?中的一種元數(shù)據(jù)功能，它接受一個對象，對象的屬性為可以通過?npm run運行的腳本，值為實際運行的命令（通常是終端命令），如：

"scripts": {
  "start": "node index.js"
},
復(fù)制代碼

• 將終端命令放入?scripts?字段，既可以記錄它們又可以實現(xiàn)輕松重用。

dependencies & devDependencies（項目依賴）

• dependencies?字段指定了項目運行所依賴的模塊
• 可以理解為我們的項目在生產(chǎn)環(huán)境運行中要用到的東西。
• 比如說我們常用的antd只能哪個代碼塊就會用到里面的組件，所以要放到dependencies里面去
• devDependencies字段指定了項目開發(fā)所需要的模塊
• 開發(fā)環(huán)境會用到的東西，比如說webpack。我們打包的時候會用到，但是項目運行的時候卻用不到，所以只需要放到devDependencies中去就好了
• 類似的eslint之類的

這里重點談一下這些版本號直接的差異

~1.1.1

• ~1.2.3:=?>=1.2.3 <1.(2+1).0:=>=1.2.3 <1.3.0-0
• ~1.2:=?>=1.2.0 <1.(2+1).0:=?>=1.2.0 <1.3.0-0(同1.2.x)
• ~1:=?>=1.0.0 <(1+1).0.0:=?>=1.0.0 <2.0.0-0(同1.x)
• ~0.2.3:=?>=0.2.3 <0.(2+1).0:=>=0.2.3 <0.3.0-0
• ~0.2:=?>=0.2.0 <0.(2+1).0:=?>=0.2.0 <0.3.0-0(同0.2.x)
• ~0:=?>=0.0.0 <(0+1).0.0:=?>=0.0.0 <1.0.0-0(同0.x)
• ~1.2.3-beta.2:=>=1.2.3-beta.2 <1.3.0-0請注意，1.2.3版本中的預(yù)發(fā)布將被允許，如果它們大于或等于beta.2. 所以，1.2.3-beta.4會被允許，但?1.2.4-beta.2不會，因為它是不同[major, minor, patch]元組的預(yù)發(fā)布。

^1.1.1

允許不修改[major, minor, patch]元組中最左邊的非零元素的更改 。換句話說，這允許版本1.0.0及以上版本的補丁和次要更新，版本的補丁更新0.X >=0.1.0，以及版本的不更新0.0.X。

許多作者將0.x版本視為x主要的“重大變化”指標。

當作者可能在發(fā)行版0.2.4和0.3.0發(fā)行版之間進行重大更改時，插入符范圍是理想的，這是一種常見做法。但是，它假定和之間不會有重大變化 。根據(jù)通常觀察到的做法，它允許進行假定為附加（但不會破壞）的更改。0.2.4``0.2.5

• ^1.2.3?:=?>=1.2.3 <2.0.0-0
• ^0.2.3?:=?>=0.2.3 <0.3.0-0
• ^0.0.3?:=?>=0.0.3 <0.0.4-0
• ^1.2.3-beta.2:=>=1.2.3-beta.2 <2.0.0-0請注意，1.2.3版本中的預(yù)發(fā)布將被允許，如果它們大于或等于beta.2. 所以，1.2.3-beta.4會被允許，但?1.2.4-beta.2不會，因為它是不同[major, minor, patch]元組的預(yù)發(fā)布。
• ^0.0.3-beta:=>=0.0.3-beta <0.0.4-0?請注意，僅允許0.0.3版本中的預(yù)發(fā)布 ，如果它們大于或等于. 所以，會被允許。beta``0.0.3-pr.2

解析插入符范圍時，缺失patch值會被減為數(shù)字0，但即使主要版本和次要版本都是0.

• ^1.2.x?:=?>=1.2.0 <2.0.0-0
• ^0.0.x?:=?>=0.0.0 <0.1.0-0
• ^0.0?:=?>=0.0.0 <0.1.0-0

缺失值minor和patch值將脫糖為零，但也允許在這些值內(nèi)具有靈活性，即使主要版本為零。

• ^1.x?:=?>=1.0.0 <2.0.0-0
• ^0.x?:=?>=0.0.0 <1.0.0-0

1.1.x

任何的X，x或*可被用來“立場在”在數(shù)字值中的一個[major, minor, patch]元組。

• *:=?>=0.0.0(任何版本都滿足)
• 1.x:=?>=1.0.0 <2.0.0-0(匹配主要版本)
• 1.2.x:=?>=1.2.0 <1.3.0-0（匹配主要和次要版本）

部分版本范圍被視為 X 范圍，因此特殊字符實際上是可選的。

• ""（空字符串）:=?*:=>=0.0.0
• 1:=?1.x.x:=>=1.0.0 <2.0.0-0
• 1.2:=?1.2.x:=>=1.2.0 <1.3.0-0

1.1.1 - 1.1.2

指定一個包含集。

• 1.2.3 - 2.3.4?:=?>=1.2.3 <=2.3.4

如果部分版本作為包含范圍中的第一個版本提供，則缺失的部分將替換為零。

• 1.2 - 2.3.4?:=?>=1.2.0 <=2.3.4

如果部分版本作為包含范圍中的第二個版本提供，則接受以元組提供的部分開頭的所有版本，但不會大于提供的元組部分。

• 1.2.3 - 2.3?:=?>=1.2.3 <2.4.0-0
• 1.2.3 - 2?:=?>=1.2.3 <3.0.0-0

engines（指定項目 node 版本）

• 有時候，新拉一個項目的時候，由于和其他開發(fā)使用的?node?版本不同，導(dǎo)致會出現(xiàn)很多奇奇怪怪的問題（如某些依賴安裝報錯、依賴安裝完項目跑步起來等）。
• 為了實現(xiàn)項目開箱即用的偉大理想，這時候可以使用?package.json?的?engines?字段來指定項目 node 版本：

"engines": {
   "node": ">= 8.16.0"
},
復(fù)制代碼

• 該字段也可以指定適用的?npm?版本：

"engines": {
   "npm": ">= 6.9.0"
 },
復(fù)制代碼

• 需要注意的是，engines屬性僅起到一個說明的作用，當用戶版本不符合指定值時也不影響依賴的安裝。

os（模塊適用系統(tǒng)）

• 假如我們開發(fā)了一個模塊，只能跑在?darwin?系統(tǒng)下，我們需要保證?windows?用戶不會安裝到該模塊，從而避免發(fā)生不必要的錯誤。
• 這時候，使用?os?屬性則可以幫助我們實現(xiàn)以上的需求，該屬性可以指定模塊適用系統(tǒng)的系統(tǒng)，或者指定不能安裝的系統(tǒng)黑名單（當在系統(tǒng)黑名單中的系統(tǒng)中安裝模塊則會報錯）：

"os" : [ "darwin", "linux" ] # 適用系統(tǒng)
"os" : [ "!win32" ] # 黑名單
復(fù)制代碼

Tips：在?node?環(huán)境下可以使用?process.platform?來判斷操作系統(tǒng)。

cpu（指定模塊適用 cpu 架構(gòu)）

• 和上面的?os?字段類似，我們可以用?cpu?字段更精準的限制用戶安裝環(huán)境：

"cpu" : [ "x64", "ia32" ] # 適用 cpu
"cpu" : [ "!arm", "!mips" ] # 黑名單
復(fù)制代碼

Tips：在?node?環(huán)境下可以使用?process.arch?來判斷?cpu?架構(gòu)。

private（定義私有模塊）

• 一般公司的非開源項目，都會設(shè)置?private?屬性的值為?true，這是因為?npm?拒絕發(fā)布私有模塊，通過設(shè)置該字段可以防止私有模塊被無意間發(fā)布出去。

次重要（可以當百科全書）

name（項目名稱）

• 這個名稱和你要發(fā)布項目到npm上的有關(guān)系。
• 假如你不想發(fā)布的話那這個name和version就不是必填項了

名字就是你的東西叫什么。（name名稱）和（version版本號）構(gòu)成一個唯一的標識符。

名稱的一些規(guī)則：

• 名稱必須小于或等于 214 個字符。這包括范圍包的范圍。
• 作用域包的名稱可以以點或下劃線開頭。這在沒有范圍的情況下是不允許的。
• 新包的名稱中不得包含大寫字母。
• 該名稱最終成為 URL 的一部分、命令行上的參數(shù)和文件夾名稱。因此，名稱不能包含任何非 URL 安全字符。

一些技巧：

• 不要使用與核心節(jié)點模塊相同的名稱。
• 不要在名稱中加入“js”或“node”。假設(shè)它是 js，因為您正在編寫 package.json 文件，并且您可以使用“engines”字段指定引擎。（見下文。）
• 該名稱可能會作為參數(shù)傳遞給 require()，因此它應(yīng)該是簡短的，但也應(yīng)該具有合理的描述性。
• 您可能需要檢查 npm 注冊表以查看是否已經(jīng)存在使用該名稱的內(nèi)容，以免過于依賴它。https://www.npmjs.com/
• 方法一：直接到npm官網(wǎng)去搜
• 方法二：npm view

如果模塊存在，可以查看該模塊的一些基本信息：

如果該模塊名從未被使用過，則會拋出 404 錯誤：

version（版本號）

• version和name組成在npm內(nèi)部的一個唯一標識符。
• 假如你不想發(fā)布的話那這個name和version就不是必填項了
• 版本必須可由node-semver解析 ，它作為依賴項與 npm 捆綁在一起。（npm install semver自己使用。）
• 我們可以執(zhí)行以下命令查看模塊的版本：

npm?view??version?#?查看某個模塊的最新版本
npm?view??versions?#?查看某個模塊的所有歷史版本

• npm view version

description（項目描述）

此文檔是您需要了解的有關(guān)?package.json?文件中所需內(nèi)容的全部信息。它必須是實際的?JSON，而不僅僅是?JavaScript對象文字。

本文檔中描述的許多行為受 中描述的配置設(shè)置的影響config。

keywords

把關(guān)鍵字放進去。它是一個字符串數(shù)組。這有助于人們發(fā)現(xiàn)您的包裹，因為它在 中列出npm search。

homepage（項目主頁）

項目主頁的url。

例子：

"homepage"?：“https://github.com/owner/project#readme”

bugs（問題追蹤）

項目問題跟蹤器的 url 和/或應(yīng)報告問題的電子郵件地址。這些對于遇到包裹問題的人很有幫助。

它應(yīng)該是這樣的：

{
??"url"?:?"https://github.com/owner/project/issues"?,??
??"email"?："[email protected]"
}

您可以指定一個或兩個值。如果您只想提供一個 url，您可以將“bugs”的值指定為一個簡單的字符串而不是一個對象。

如果提供了url，它將被npm bugs命令使用。

license（執(zhí)照）

你應(yīng)該為你的包指定一個許可證，以便人們知道他們?nèi)绾伪辉试S使用它，以及你對它施加的任何限制。

如果您使用的是 BSD-2-Clause 或 MIT 等通用許可證，請為您使用的許可證添加當前的SPDX?許可證標識符，如下所示：

{
??"license"?:?"BSD-3-Clause"
}

您可以查看SPDX 許可證 ID 的完整列表。理想情況下，您應(yīng)該選擇 OSI批準的一種。

如果您的軟件包在多個通用許可下獲得許可，請使用SPDX 許可表達式語法版本 2.0 string，如下所示：

{
??"license"?:?"(ISC?OR?GPL-3.0)"
}

如果您使用的許可證尚未分配SPDX?標識符，或者您使用的是自定義許可證，請使用如下字符串值：

{
??"license"?:?"SEE?LICENSE?IN?"
}

然后包含一個在包的頂層命名的文件。

一些舊包使用許可證對象或包含許可證對象數(shù)組的“許可證”屬性：

//?無效的元數(shù)據(jù)
{
??"license"?:?{
????"type"?:?"ISC",
????"url"?:?"https://opensource.org/licenses/ISC"
??}
}

//?無效的元數(shù)據(jù)
{
??"licenses"?:?[
????{
??????"type":?"MIT",
??????"url":?"https://www.opensource.org/licenses/mit-license.php"
????},
????{
??????"type":?"Apache-2.0",
??????"url":?"https://opensource.org/licenses/apache2.0.php"
????}
??]
}

這些樣式現(xiàn)在已被棄用。相反，使用SPDX表達式，如下所示：

{
??"license":?"ISC"
}
{
??"license":?"(MIT?OR?Apache-2.0)"
}

最后，如果您不希望根據(jù)任何條款授予他人使用私有或未發(fā)布包的權(quán)利：

{
??"license":?"UNLICENSED"
}

還要考慮設(shè)置"private": true以防止意外發(fā)布。

author, contributors（作者和貢獻者）

“作者”是一個人。“貢獻者”是一群人。“person”是一個帶有“name”字段和可選的“url”和“email”的對象，像這樣：

{
??"name"?:?"Barney?Rubble",
??"email"?:?"[email protected]",
??"url"?:?"http://barnyrubble.tumblr.com/"
}

或者，您可以將其全部縮短為一個字符串，然后 npm 將為您解析它：

{
??"author":?"Barney?Rubble??(http://barnyrubble.tumblr.com/)"
}

email 和 url 都是可選的。

npm 還使用您的 npm 用戶信息設(shè)置頂級“維護者”字段。

funding（檔案）

可選files字段是一個文件模式數(shù)組，它描述了當您的包作為依賴項安裝時要包含的條目。文件模式遵循與 類似的語法.gitignore，但相反：包含文件、目錄或 glob 模式（*,**/*等）將使該文件在打包時包含在 tarball 中。省略該字段將使其默認為["*"]，這意味著它將包含所有文件。

一些特殊的文件和目錄也會被包含或排除，無論它們是否存在于files數(shù)組中（見下文）。

您還可以.npmignore在包的根目錄或子目錄中提供一個文件，以防止文件被包含在內(nèi)。在包的根目錄中，它不會覆蓋“文件”字段，但在子目錄中會覆蓋。該.npmignore文件就像一個.gitignore. 如果有一個.gitignore文件，并且.npmignore丟失了，.gitignore則將使用 的內(nèi)容。

文件包含了“的package.json＃文件”欄中無法通過排除.npmignore或.gitignore。

無論設(shè)置如何，始終包含某些文件：

• package.json
• README
• CHANGES/?CHANGELOG/HISTORY
• LICENSE?/?LICENCE
• NOTICE
• “主要”字段中的文件

README,?CHANGES,?LICENSE&NOTICE可以有任何大小寫和擴展名。

相反，一些文件總是被忽略：

• .git
• CVS
• .svn
• .hg
• .lock-wscript
• .wafpickle-N
• .*.swp
• .DS_Store
• ._*
• npm-debug.log
• .npmrc
• node_modules
• config.gypi
• *.orig
• package-lock.json（?npm-shrinkwrap.json如果您希望發(fā)布，請使用）

main（主要入口）

• main?字段是?package.json?中的另一種元數(shù)據(jù)功能，它可以用來指定加載的入口文件。假如你的項目是一個?npm?包，當用戶安裝你的包后，require('my-module')?返回的是?main?字段中所列出文件的?module.exports?屬性。
• 當不指定main?字段時，默認值是模塊根目錄下面的index.js?文件。

browser（瀏覽器）

如果您的模塊打算在客戶端使用，則應(yīng)使用瀏覽器字段而不是主字段。這有助于提示用戶它可能依賴于 Node.js 模塊中不可用的原語。（例如?window）

bin（自定義命令）

很多包都有一個或多個他們想要安裝到 PATH 中的可執(zhí)行文件。npm 使這變得非常簡單（實際上，它使用此功能來安裝“npm”可執(zhí)行文件。）

要使用它，請bin在 package.json 中提供一個字段，它是命令名到本地文件名的映射。在安裝時，npm 會將該文件符號鏈接到prefix/bin全局安裝或./node_modules/.bin/本地安裝。

給大家看看我自己做一個簡單的demo：

{
??"name":?"react-cli-library",
??"version":?"0.0.2",
??"description":?"",
??"bin":?{
????"react-cli":?"./bin/index.js"
??},
}

我的名稱叫做react-cli-library。

所以，npm i react-cli-library

安裝完成之后，執(zhí)行react-cli就會有一些命令，他會執(zhí)行我的根目錄底下./bin/index.js這個文件。

雖然我的項目名稱是：react-cli-library。但是我執(zhí)行的內(nèi)容卻是react-cli，這個取決于bin的內(nèi)容

man（快捷入口）

用來給Linux下的man命令查找文檔地址，是個單一文件或者文件數(shù)組。如果是單一文件，安裝完成后，他就是man + 的結(jié)果，和此文件名無關(guān)，例如：

{
  "name": "foo",
  "version": "1.2.3",
  "description": "A packaged foo fooer for fooing foos",
  "main": "foo.js",
  "man": "./man/doc.1"
}

通過man foo命令會得到 ./man/doc.1 文件的內(nèi)容。如果man文件名稱不是以模塊名稱開頭的，安裝的時候會給加上模塊名稱前綴。因此，下面這段配置：

{
  "name": "foo",
  "version": "1.2.3",
  "description": "A packaged foo fooer for fooing foos",
  "main": "foo.js",
  "man": [
    "./man/foo.1",
    "./man/bar.1"
  ]
}

會創(chuàng)建一些文件來作為man foo和man foo-bar命令的結(jié)果。man文件必須以數(shù)字結(jié)尾，或者如果被壓縮了，以.gz結(jié)尾。數(shù)字表示文件將被安裝到man的哪個部分。

{
  "name": "foo",
  "version": "1.2.3",
  "description": "A packaged foo fooer for fooing foos",
  "main": "foo.js",
  "man": [
    "./man/foo.1",
    "./man/foo.2"
  ]
}

會創(chuàng)建 man foo 和 man 2 foo 兩條命令。

directories（目錄）

CommonJS Packages規(guī)范詳細說明了一些可以使用directories對象指示包結(jié)構(gòu)的方法。如果您查看npm 的 package.json，您會看到它包含 doc、lib 和 man 目錄。

將來，這些信息可能會以其他創(chuàng)造性的方式使用。

目錄.bin

如果在 中指定bin目錄directories.bin，則將添加該文件夾中的所有文件。

由于bin指令的工作方式，同時指定bin路徑和設(shè)置directories.bin是錯誤的。如果要指定單個文件，請使用bin，對于現(xiàn)有bin?目錄中的所有文件，請使用directories.bin。

目錄.man

一個充滿手冊頁的文件夾。Sugar 通過遍歷文件夾來生成“man”數(shù)組。

repository（代碼存儲位置）

指定代碼所在的位置。這對想要貢獻的人很有幫助。如果 git repo 在 GitHub 上，那么該npm docs?命令將能夠找到您。

像這樣做：

{
??"repository":?{
????"type":?"git",
????"url":?"https://github.com/npm/cli.git"
??}
}

URL 應(yīng)該是一個公開可用的（可能是只讀的）url，可以直接傳遞給 VCS 程序，無需任何修改。它不應(yīng)該是您放入瀏覽器的 html 項目頁面的 url。是給電腦用的。

對于 GitHub、GitHub gist、Bitbucket 或 GitLab 存儲庫，您可以使用與 相同的快捷語法npm install：

{
??"repository":?"npm/npm",

??"repository":?"github:user/repo",

??"repository":?"gist:11081aaa281",

??"repository":?"bitbucket:user/repo",

??"repository":?"gitlab:user/repo"
}

如果package.json您的包的 不在根目錄中（例如，如果它是 monorepo 的一部分），您可以指定它所在的目錄：

{
??"repository":?{
????"type":?"git",
????"url":?"https://github.com/facebook/react.git",
????"directory":?"packages/react-dom"
??}
}

config（配置內(nèi)容）

“config”對象可用于設(shè)置在升級過程中持續(xù)存在的包腳本中使用的配置參數(shù)。例如，如果一個包具有以下內(nèi)容：

{
??"name":?"foo",
??"config":?{
????"port":?"8080"
??}
}

然后有一個“開始”命令，然后引用?npm_package_config_port環(huán)境變量，然后用戶可以通過執(zhí)行npm config set foo:port 8001.

查看config和scripts了解更多關(guān)于包配置的信息。

peerDependencies（對等依賴）

在某些情況下，您希望表達您的包與主機工具或庫的兼容性，而不必執(zhí)行require此主機的操作。這通常稱為插件。值得注意的是，您的模塊可能會公開主機文檔所預(yù)期和指定的特定接口。

例如：

{
??"name":?"tea-latte",
??"version":?"1.3.5",
??"peerDependencies":?{
????"tea":?"2.x"
??}
}

這確保您的軟件包tea-latte只能與主機軟件包的第二個主要版本一起安裝tea。npm install tea-latte可能會產(chǎn)生以下依賴圖：

├──[email protected]
└──[email protected]

在 npm 版本 3 到 6 中，peerDependencies不會自動安裝，如果在樹中發(fā)現(xiàn)對等依賴項的無效版本，則會發(fā)出警告。由于NPM V7的，peerDependencies被?默認安裝。

如果無法正確解析樹，嘗試安裝具有沖突要求的另一個插件可能會導(dǎo)致錯誤。因此，請確保您的插件要求盡可能廣泛，而不是將其鎖定為特定的補丁版本。

假設(shè)主機符合semver，只有主機包的主要版本中的更改才會破壞您的插件。因此，如果您使用過主機包的每個 1.x 版本，請使用"^1.0"或"1.x"?來表達這一點。如果您依賴 1.5.2 中引入的功能，請使用?"^1.5.2".

peerDependenciesMeta（捆綁依賴）

這定義了在發(fā)布包時將捆綁的包名稱數(shù)組。

如果您需要在本地保留 npm 包或通過單個文件下載使它們可用，您可以通過在bundledDependencies?數(shù)組中指定包名稱并執(zhí)行npm pack.

例如：

如果我們像這樣定義 package.json：

{
??"name":?"awesome-web-framework",
??"version":?"1.0.0",
??"bundledDependencies":?[
????"renderized",
????"super-streams"
??]
}

我們可以awesome-web-framework-1.0.0.tgz通過運行獲取文件npm pack。此文件包含的依賴關(guān)系renderized，并super-streams可以通過執(zhí)行安裝在一個新的項目npm install awesome-web-framework-1.0.0.tgz。請注意，包名稱不包含任何版本，因為該信息在dependencies.

如果這是拼寫"bundleDependencies"，那么這也很榮幸。

optionalDependencies（可選依賴項）

如果可以使用依賴項，但如果找不到或安裝失敗，您希望 npm 繼續(xù)，那么您可以將其放入?optionalDependencies對象中。這是包名稱到版本或 url 的映射，就像dependencies對象一樣。不同之處在于構(gòu)建失敗不會導(dǎo)致安裝失敗。運行npm install --no-optional將阻止安裝這些依賴項。

處理缺少依賴項仍然是您的程序的責任。例如，這樣的事情：

try?{
??var?foo?=?require('foo')
??var?fooVersion?=?require('foo/package.json').version
}?catch?(er)?{
??foo?=?null
}
if?(?notGoodFooVersion(fooVersion)?)?{
??foo?=?null
}

//?..?then?later?in?your?program?..

if?(foo)?{
??foo.doFooThings()
}

中的條目optionalDependencies將覆蓋 中的同名條目?dependencies，因此通常最好只放在一個地方。

publishConfig（發(fā)布配置）

這是一組將在發(fā)布時使用的配置值。如果您想設(shè)置標記、注冊表或訪問權(quán)限，這將特別方便，這樣您就可以確保給定的包沒有被標記為“最新”、未發(fā)布到全局公共注冊表或默認情況下范圍模塊是私有的。

查看config可覆蓋的配置選項列表。

workspaces（工作區(qū)）

可選workspaces字段是一個文件模式數(shù)組，它描述了本地文件系統(tǒng)內(nèi)的位置，安裝客戶端應(yīng)該查找這些位置以找到需要符號鏈接到頂級文件夾的每個工作區(qū)node_modules。

它可以描述要用作工作區(qū)的文件夾的直接路徑，也可以定義將解析為這些相同文件夾的 glob。

在以下示例中，./packages只要文件夾中包含有效package.json文件，位于文件夾內(nèi)的所有文件夾 都將被視為工作區(qū) ：

{
??"name":?"workspace-example",
??"workspaces":?[
????"./packages/*"
??]
}

有關(guān)workspaces更多示例，請參見。

總結(jié)

本文幾乎是全網(wǎng)最全的package.json的講解了。一些常用的和不常用的都有區(qū)分，不常用的可以當百科全書查一下，面試主要也是會問一些主要內(nèi)容。