全方位解讀 package.json

作者Derrick
https://zhuanlan.zhihu.com/p/384484213

前言

平常在工作中，對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"
},
復制代碼

• 將終端命令放入 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版本中的預發(fā)布將被允許，如果它們大于或等于beta.2. 所以，1.2.3-beta.4會被允許，但 1.2.4-beta.2不會，因為它是不同[major, minor, patch]元組的預發(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版本中的預發(fā)布將被允許，如果它們大于或等于beta.2. 所以，1.2.3-beta.4會被允許，但 1.2.4-beta.2不會，因為它是不同[major, minor, patch]元組的預發(fā)布。
• ^0.0.3-beta:=>=0.0.3-beta <0.0.4-0 請注意，僅允許0.0.3版本中的預發(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 版本不同，導致會出現(xiàn)很多奇奇怪怪的問題（如某些依賴安裝報錯、依賴安裝完項目跑步起來等）。
• 為了實現(xiàn)項目開箱即用的偉大理想，這時候可以使用 package.json 的 engines 字段來指定項目 node 版本：

"engines": {
   "node": ">= 8.16.0"
},
復制代碼

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

"engines": {
   "npm": ">= 6.9.0"
 },
復制代碼

• 需要注意的是，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" ] # 黑名單
復制代碼

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

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

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

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

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()，因此它應該是簡短的，但也應該具有合理的描述性。
• 您可能需要檢查 npm 注冊表以查看是否已經(jīng)存在使用該名稱的內(nèi)容，以免過于依賴它。https://www.npmjs.com/
• 方法一：直接到npm官網(wǎng)去搜
• 方法二：npm view <packageName>

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

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

version（版本號）

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

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

• npm view <packageName> 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 和/或應報告問題的電子郵件地址。這些對于遇到包裹問題的人很有幫助。

它應該是這樣的：

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

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

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

license（執(zhí)照）

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

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

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

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

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

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

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

{
  "license" : "SEE LICENSE IN <filename>"
}

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

一些舊包使用許可證對象或包含許可證對象數(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（作者和貢獻者）

“作者”是一個人?！柏暙I者”是一群人?！皃erson”是一個帶有“name”字段和可選的“url”和“email”的對象，像這樣：

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

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

{
  "author": "Barney Rubble <[email protected]> (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（瀏覽器）

如果您的模塊打算在客戶端使用，則應使用瀏覽器字段而不是主字段。這有助于提示用戶它可能依賴于 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 應該是一個公開可用的（可能是只讀的）url，可以直接傳遞給 VCS 程序，無需任何修改。它不應該是您放入瀏覽器的 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此主機的操作。這通常稱為插件。值得注意的是，您的模塊可能會公開主機文檔所預期和指定的特定接口。

例如：

{
  "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被 默認安裝。

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

假設(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)建失敗不會導致安裝失敗。運行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)的位置，安裝客戶端應該查找這些位置以找到需要符號鏈接到頂級文件夾的每個工作區(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)容。

歡迎自薦投稿到《前端技術(shù)江湖》，如果你覺得這篇內(nèi)容對你挺有啟發(fā)，記得點個 「在看」哦