Node.js中package.json詳解

1.?name（名稱）

如果你計劃發布你的包，package.json 中最重要的字段是 name 和 version，因為它們是必需的。name 和 version 共同組成一個假定完全唯一的標識符。包的更改應伴隨版本號的更新。如果你不打算發布包，那么 name 和 version 字段是可選的。

name 就是你包的名稱。

一些規則：

名稱必須少于或等于 214 個字符。這包括范圍包的范圍部分。
范圍包的名稱可以以點（.）或下劃線（_）開頭。如果沒有范圍，則不允許這樣做。
新包的名稱不能包含大寫字母。
名稱將成為 URL 的一部分、命令行中的參數以及文件名。因此，名稱不能包含任何非 URL 安全的字符。

一些建議：

不要使用與 Node 核心模塊相同的名稱。
不要在名稱中使用 "js" 或 "node"。因為你正在編寫 package.json 文件，默認情況下它是 JavaScript 項目，你可以通過 engines 字段指定運行環境。
名稱可能會被傳遞給 require()，因此它應短小且具有描述性。
在命名之前，建議檢查 npm 注冊表，以確認是否已經存在相同名稱的包：https://www.npmjs.com/
名稱可以選擇性地添加范圍前綴，例如 @myorg/mypackage。詳細信息請參閱 scope

2. version（版本）

如果你計劃發布包，package.json 中最重要的字段是 name 和 version，因為它們是必須的。name 和 version 共同構成唯一的標識符。包的更改應伴隨版本號的更新。如果你不打算發布包，那么 name 和 version 字段是可選的。

版本號必須能夠通過node-semver 解析，它作為 npm 的依賴項捆綁在一起，當然你也可以通過 npm install semver 來單獨使用它。

3. description（描述）

為包添加描述。它是一個字符串，有助于用戶通過 npm search 搜索到你的包。

4. keywords（關鍵詞）

為包添加關鍵詞。它是一個字符串數組，能夠幫助用戶通過 npm search 搜索到你的包。

5.?homepage（主頁）

項目主頁的 URL。

 "homepage": "https://github.com/owner/project#readme"

6.?bugs（問題報告）

項目的問題跟蹤 URL 和/或用于報告問題的電子郵件地址。當人們遇到包的問題時，這些信息很有幫助。

應該是這樣的格式：

{"bugs": {"url": "https://github.com/owner/project/issues","email": "project@hostname.com"}
}

你可以只指定 URL，也可以同時指定 URL 和電子郵件。如果只想提供 URL，可以將 bugs 字段值寫成一個簡單的字符串而不是對象。

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

7. license（許可證）

你應該為包指定一個許可證，這樣人們才能知道如何被允許使用它以及你施加的任何限制。

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

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

你可以查看 SPDX 許可證 ID 列表。理想情況下，你應該選擇一個由 OSI 批準的許可證。

如果你的包受多個常見許可證保護，請使用 SPDX 許可證表達式語法 2.0 字符串，例如：

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

如果你使用的許可證沒有被分配 SPDX 標識符，或者你使用自定義許可證，請使用如下字符串：

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

然后在包的頂層目錄中包含一個名為 <filename> 的文件。

一些舊的包使用了許可證對象或包含許可證對象數組的 "licenses" 屬性：

{// 非有效元數據"license": {"type": "ISC","url": "https://opensource.org/licenses/ISC"}
}{// 非有效元數據"licenses": [{"type": "MIT","url": "https://www.opensource.org/licenses/mit-license.php"},{"type": "Apache-2.0","url": "https://opensource.org/licenses/apache2.0.php"}]
}

這些風格現在已經被棄用。應該改用 SPDX 表達式，如下所示：

{"license": "ISC"
}

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

如果你不希望他人在任何條件下使用私有或未發布的包，請使用：

{"license": "UNLICENSED"
}

此外，考慮將 private 設置為 true，以防止包意外發布。

8. people fields: author, contributors（人員字段：作者、貢獻者）

author 表示一個人，contributors 是一個人員數組。一個 "person" 是一個包含 name 字段的對象，可選的 email 和 url 字段，如下所示：

{"name": "Barney Rubble","email": "b@rubble.com","url": "http://barnyrubble.tumblr.com/"
}

或者你可以將其簡寫為一個字符串，npm 會自動解析它：

{"author": "Barney Rubble <b@rubble.com> (http://barnyrubble.tumblr.com/)"
}

無論是 email 還是 url 都是可選的。

npm 還會使用你的 npm 用戶信息設置頂級 maintainers 字段。

9.?funding（資助）

你可以指定一個包含資助信息的 URL，提供用于幫助資助開發的信息。它可以是一個字符串 URL，或者是一個對象數組和字符串 URL 的組合。

{"funding": {"type": "individual","url": "http://example.com/donate"}
}

{"funding": {"type": "patreon","url": "https://www.patreon.com/my-account"}
}

{"funding": "http://example.com/donate"
}

{"funding": [{"type": "individual","url": "http://example.com/donate"},"http://example.com/donateAlso",{"type": "patreon","url": "https://www.patreon.com/my-account"}]
}

用戶可以使用 npm fund 子命令列出項目依賴項（直接或間接）的資助 URL。你還可以使用 npm fund <projectname> 來訪問每個資助 URL（如果有多個 URL，則會訪問第一個）。

10. files（文件）

可選的 files 字段是一個文件模式數組，描述當你的包作為依賴項安裝時應包含的條目。文件模式的語法類似于 .gitignore，但相反：包括的文件、目錄或通配符模式（如 *，**/* 等）將在打包時被包含。省略該字段將默認為 ["*"]，這意味著它將包含所有文件。

某些特殊文件和目錄也會被包含或排除，無論它們是否存在于 files 數組中。

你還可以在包的根目錄或子目錄中提供 .npmignore 文件，該文件可以防止某些文件被包含。在根目錄中，它不會覆蓋 files 字段，但在子目錄中會覆蓋。.npmignore 文件的工作方式與 .gitignore 類似。如果存在 .gitignore 文件，但沒有 .npmignore 文件，.gitignore 的內容將被使用。

某些文件總是會被包含，無論設置如何：

package.json
README
LICENSE / LICENCE
main 字段中的文件
bin 字段中的文件

README 和 LICENSE 可以具有任意大小寫和擴展名。

某些文件總是默認被忽略：

*.orig
*.swp
.DS_Store
._*
.git
.hg
.lock-wscript
.npmrc
.svn
.wafpickle
CVS
config.gypi
node_modules
npm-debug.log
package-lock.json（如果希望它被發布，請使用 npm-shrinkwrap.json）
pnpm-lock.yaml
yarn.lock

大多數這些被忽略的文件可以通過在 files 字段中明確包含來包含，但以下文件不能被包含：

.git
.npmrc
node_modules
package-lock.json
pnpm-lock.yaml
yarn.lock

這些文件無法被包含。

11. exports（導出）

exports 提供了一種現代替代 main 的方式，允許定義多個入口點，支持環境之間的條件解析，并防止除了 exports 定義的入口點以外的任何其他入口點被訪問。這種封裝允許模塊作者明確定義包的公共接口。有關更多詳細信息，請參閱 Node.js 文檔中的包入口點。

12. main（主文件）

main 字段是一個模塊 ID，表示程序的主要入口點。也就是說，如果你的包名為 foo，用戶安裝了它并執行了 require("foo")，則會返回你 main 模塊的 exports 對象。

這應該是相對于包根目錄的模塊路徑。

對于大多數模塊，最合理的做法是提供一個主要腳本，通常沒有其他文件。

如果 main 未設置，則默認使用包根目錄中的 index.js。

13.?browser（瀏覽器）

如果你的模塊是為了客戶端使用的，browser 字段應該被用于替代 main 字段。這有助于提示用戶模塊可能依賴于 Node.js 模塊中不可用的瀏覽器原生 API。

14.?bin（可執行文件）

許多包有一個或多個希望安裝到 PATH 中的可執行文件。npm 讓這件事變得非常容易，npm 自己就是通過這種功能來安裝的。

要使用它，在 package.json 中提供一個 bin 字段，它是命令名稱到本地文件名的映射。當包被全局安裝時，該文件將被接到全局 bin 目錄中，或者在 Windows 上創建一個 cmd 文件，執行 bin 字段中指定的文件，從而可以通過 name 或 name.cmd 運行它們。當該包作為另一個包的依賴項安裝時，該文件將被鏈接，使得它可以直接通過 npm exec 或其他腳本中的 npm run-script 命令使用。

例如，myapp 可以這樣定義：

{"bin": {"myapp": "bin/cli.js"}
}

因此，當你安裝 myapp 時，在類 Unix 操作系統中，它會從 cli.js 腳本創建一個符號鏈接到 /usr/local/bin/myapp，在 Windows 中，它會創建一個 cmd 文件，通常位于 C:\Users\{Username}\AppData\Roaming\npm\myapp.cmd，它會運行 cli.js 腳本。

如果你有一個可執行文件，并且它的名稱應該與包的名稱相同，那么你可以將其作為字符串提供。例如：

{"name": "my-program","version": "1.2.5","bin": "path/to/program"
}

相當于：

{"name": "my-program","version": "1.2.5","bin": {"my-program": "path/to/program"}
}

請確保 bin 中引用的文件以 #!/usr/bin/env node 開頭，否則腳本將無法使用 node 可執行文件啟動。

注意，你也可以使用 directories.bin字段設置可執行文件。

15. man（手冊）

指定一個單獨的文件或文件名數組，使其可以通過 man 程序找到。

如果只提供一個文件，它將被安裝為 man <pkgname> 的結果，而不管其實際文件名是什么。例如：

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

將 ./man/doc.1 文件鏈接為 man foo 的目標。

如果文件名不以包名開頭，則會添加前綴。例如：

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

將創建 foo.1 和 bar.1的條目。

手冊文件必須以數字結尾，并且如果它們被壓縮，則可以選擇 .gz 后綴。數字決定了文件安裝到哪個手冊部分。

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

將創建 foo.1 和?foo.2的條目。

16. directories（目錄）

CommonJS Packages 規范詳細說明了如何使用 directories 對象指示包的結構。如果你查看 npm 的 package.json，你會發現它有 doc、lib 和 man 目錄。

未來，此信息可能會以其他創新方式使用。

16.1. directories.bin

如果你在 directories.bin 中指定了一個 bin 目錄，該文件夾中的所有文件都將被添加。

由于 bin 指令的工作方式，指定 bin 路徑并同時設置 directories.bin 是一個錯誤。如果你想要指定單個文件，請使用 bin，如果要包含現有 bin 目錄中的所有文件，請使用 directories.bin。

16.2. directories.man

一個包含手冊頁面的文件夾。通過遍歷文件夾生成一個 "man" 數組的語法糖。

17. repository（倉庫）

指定代碼存放的位置。這對于想要貢獻的人來說很有幫助。如果 git 倉庫在 GitHub 上，那么 npm repo 命令將能夠找到你。

"repository": {"type": "git","url": "git+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": "git+https://github.com/npm/cli.git","directory": "workspaces/libnpmpublish"
}

18. scripts (腳本)

scripts 屬性是一個字典，包含在包生命周期的不同階段運行的腳本命令。鍵是生命周期事件，值是運行的命令。

更多關于編寫包腳本的內容，請參閱 scripts。

19. config (配置)

config 對象可以用來設置包腳本中使用的配置參數，并在升級時保留。例如，如果包有以下內容：

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

它還可以有一個 start 命令，引用 npm_package_config_port 環境變量。

20.?dependencies（依賴項）

dependencies 是一個簡單的對象，映射包名稱到版本范圍。版本范圍是一個包含一個或多個空格分隔描述符的字符串。依賴項也可以通過 tarball 或 git URL 指定。

請不要將測試框架、轉譯器或其他“開發”工具放在 dependencies ?對象中。有關詳細信息，請參閱 devDependencies。

有關版本范圍的更多信息，請參閱 semver。

version 必須與 version 完全匹配。
>version 必須大于 version 。
=version 等。
<version 。
<=version 。
~version “大致等于版本”。參見 semver。
^version “與版本兼容”。參見 semver。
1.2.x 1.2.0、1.2.1 等，但不包括 1.3.0。
http://... 參見下文中的 'URLs as Dependencies'。
* 匹配任何版本。

""（空字符串）等同于 *。
version1 - version2 等同于 >=version1 <=version2 。
range1 || range2 如果滿足 range1 或 range2，則通過。
git ... 參見下文中的 'Git URLs as Dependencies'。
user/repo 參見下文中的 'GitHub URLs'。
tag 指定標記并發布為 tag 的特定版本。參見 npm dist-tag?
path/path/path 參見下文中的 'Local Paths'。
npm:@scope/pkg@version 自定義別名。參見 package-spec

以下都是有效的：

{"dependencies": {"foo": "1.0.0 - 2.9999.9999","bar": ">=1.0.2 <2.1.2","baz": ">1.0.2 <=2.3.4","boo": "2.0.1","qux": "<1.0.0 || >=2.3.1 <2.4.5 || >=2.5.2 <3.0.0","asd": "http://asdf.com/asdf.tar.gz","til": "~1.2","elf": "~1.2.3","two": "2.x","thr": "3.3.x","lat": "latest","dy1": "file:../dy1","kpg": "npm:pkg@1.0.0"}
}

20.1.?URLs as Dependencies（URL 作為依賴項）

你可以用 tarball URL 替代版本范圍。

在安裝時，該 tarball 將被下載并本地安裝到你的包中。

20.2.?Git URLs as Dependencies（Git URL 作為依賴項）

Git URL 的格式為：

<protocol>://[<user>[:<password>]@]<hostname>[:<port>][/]<path>[#<commit-ish> | #semver:<semver>]

<protocol> 可以是 git 、 git+ssh 、 git+http 、 git+https 或 git+file 。

如果提供了 #<commit-ish>，它將用于克隆該確切的提交。如果 commit-ish 具有格式 #semver:semver ，<semver> 可以是任何有效的 semver 范圍或確切版本，npm 將查找匹配該范圍的標簽或 refs，就像它為注冊表依賴項做的一樣。如果既沒有指定 #commit-ish 也沒有指定 #semver:semver，則使用默認分支。

git+ssh://git@github.com:npm/cli.git#v1.0.27
git+ssh://git@github.com/npm/cli#semver:^5.0
git+https://isaacs@github.com/npm/cli.git
git://github.com/npm/cli.git#v1.0.27

當從 git 倉庫安裝時，package.json 中的某些字段將導致 npm 認為需要進行構建。為此，npm 將克隆你的倉庫到一個臨時目錄，安裝其所有依賴項，運行相關腳本，然后打包并安裝結果目錄。

如果你的 git 依賴項使用了 workspaces，或者存在以下腳本中的任何一個，npm 將進行這種流程：

build
prepare
prepack
preinstall
install
postinstall

如果你的 git 倉庫包含預構建的產物，你可能希望確保沒有定義這些腳本，否則每次安裝時都會重新構建依賴項。

20.3.?GitHub URLs（GitHub URL）

從版本 1.1.65 開始，你可以僅使用 "foo": "user/foo-project" 的方式引用 GitHub URL。就像 git URL 一樣，可以包含 <commit-ish>

{"name": "foo","version": "0.0.0","dependencies": {"express": "expressjs/express","mocha": "mochajs/mocha#4727d357ea","module": "user/repo#feature/branch"}
}

20.4.?Local Paths（本地路徑）

從版本 2.0.0 開始，你可以提供指向包含包的本地目錄的路徑。可以通過 npm install -S 或 npm install --save 保存本地路徑，使用以下任意形式：

../foo/bar
~/foo/bar
./foo/bar
/foo/bar

它們將被標準化為相對路徑并添加到 package.json 中。例如：

{"name": "baz","dependencies": {"bar": "file:../foo/bar"}
}

此功能對于本地離線開發和需要 npm 安裝但不希望連接外部服務器的測試非常有用，但不應發布到公共注冊表時使用。

注意：通過本地路徑鏈接的包在運行 npm install 時不會安裝其自己的依賴項。你必須從本地路徑內部運行 npm install。

21.?devDependencies（開發依賴）

如果有人計劃在他們的程序中下載并使用你的模塊，那么他們可能不希望或不需要下載和構建你使用的外部測試或文檔框架。

在這種情況下，最好將這些額外的項目映射到 devDependencies 對象中。

這些項目在執行 npm link 或從包根目錄運行 npm install 時會被安裝，并且可以像任何其他 npm 配置參數一樣進行管理。有關更多信息，請參閱 config。

對于與平臺無關的構建步驟，例如將 CoffeeScript 或其他語言編譯為 JavaScript，使用 prepare 腳本來完成此操作，并將所需的包作為開發依賴項。

{"name": "ethopia-waza","description": "a delightfully fruity coffee varietal","version": "1.2.3","devDependencies": {"coffee-script": "~1.6.3"},"scripts": {"prepare": "coffee -o lib/ -c src/waza.coffee"},"main": "lib/waza.js"
}

prepare 腳本將在發布前運行，這樣用戶可以在不需要自己編譯的情況下使用功能。在開發模式下，此腳本也會運行，以便于測試。

22. peerDependencies (對等依賴)

在某些情況下，你可能需要表示你的包與主工具或庫的兼容性，而不一定對其進行 require。這通常被稱為插件。特別是，你的模塊可能會公開一個特定的接口，主包會根據文檔來期望和指定這個接口。

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

這可以確保你的包 tea-latte 只能與主包 tea 的第二個大版本一起安裝。運行 npm install tea-latte 可能會生成以下依賴關系圖：

├─ tea-latte@1.3.5
└─ tea@2.2.0

在 npm 版本 3 到 6 之間，peerDependencies 不會自動安裝，如果發現無效版本的對等依賴項，npm 將發出警告。從 npm v7 開始，peerDependencies 默認會被安裝。

嘗試安裝另一個有沖突要求的插件可能會導致錯誤，特別是在依賴樹無法正確解析時。因此，確保插件的要求盡可能寬泛，并且不要將其鎖定為特定補丁版本。

假設主包遵循 semver，只有主包的大版本號變更才會破壞插件。因此，如果你的插件與主包的每個 1.x 版本都兼容，請使用 "^1.0" 或 "1.x" 來表達這一點。如果你依賴于 1.5.2 中引入的功能，請使用 "^1.5.2"。

23.?peerDependenciesMeta（對等依賴元信息）

peerDependenciesMeta 字段為 npm 提供了更多關于如何使用對等依賴的信息。特別是，它允許將對等依賴標記為可選。npm 不會自動安裝可選的對等依賴。這樣，你可以與各種主包集成和交互，而無需安裝所有主包。

{"name": "tea-latte","version": "1.3.5","peerDependencies": {"tea": "2.x","soy-milk": "1.2"},"peerDependenciesMeta": {"soy-milk": {"optional": true}}
}

24. bundleDependencies（捆綁依賴項）

此字段定義了發布包時要捆綁的包名數組。

在某些情況下，你需要本地保留 npm 包或通過單個文件下載它們。你可以通過在 bundleDependencies 數組中指定包名并執行 npm pack 來實現此目的。

如果我們定義了一個如下所示的 package.json 文件：

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

運行 npm pack 將生成 awesome-web-framework-1.0.0.tgz 文件。該文件包含 renderized 和 super-streams 依賴項，可以通過執行 npm install awesome-web-framework-1.0.0.tgz 在新項目中安裝這些依賴項。請注意，包名不包括任何版本信息，因為這些信息在 dependencies 中已經指定。

如果將其拼寫為 "bundledDependencies"，它也會被接受。或者，"bundleDependencies" 也可以定義為布爾值。true 表示將捆綁所有依賴項，false 表示不捆綁任何依賴項。

25. optionalDependencies（可選依賴）

如果某個依賴項可以使用，但你希望即使它找不到或安裝失敗，npm 也能繼續安裝，那么可以將其放在 optionalDependencies 對象中。這個對象的結構與 dependencies 類似，是包名到版本或 URL 的映射。區別在于構建失敗不會導致安裝失敗。運行 npm install --omit=optional 將阻止安裝這些依賴項。

仍然是你的程序需要處理沒有依賴項的情況。例如，可以這樣做：

try {var foo = require('foo')var fooversion = require('foo/package.json').version
} catch (er) {foo = null
}
if ( notGoodFooversion(fooversion) ) {foo = null
}// ..然后在你的程序的某處..if (foo) {foo.doFooThings()
}

optionalDependencies 中的條目將覆蓋 dependencies 中相同名稱的條目，因此最好只在一個地方聲明依賴項。

26. overrides（覆蓋）

如果你需要對依賴項的依賴項進行特定更改，例如替換具有已知安全問題的依賴版本、將現有依賴項替換為分支版本，或者確保某個包的相同版本在所有地方都被使用，那么你可以添加一個覆蓋。

覆蓋允許將依賴樹中的包替換為另一個版本或完全替換為另一個包。這些更改可以指定得非常具體或非常寬泛。

覆蓋僅在項目的根 package.json 文件中生效。已安裝依賴項（包括 workspaces）中的覆蓋不會被考慮。已發布的包可以通過固定依賴項或使用 npm-shrinkwrap.json 文件來控制其解析。

要確保包 foo 始終安裝為版本 1.0.0，無論你的依賴項依賴于哪個版本：

{"overrides": {"foo": "1.0.0"}
}

上面是簡寫形式，完整的對象形式允許覆蓋包本身以及其子項。這將確保 foo 始終是 1.0.0，同時也會讓 bar 在任何深度上始終是 1.0.0：

{"overrides": {"foo": {".": "1.0.0","bar": "1.0.0"}}
}

僅當 foo 是包 bar 的子包（或孫子包、曾孫子包等）時，才覆蓋 foo 為 1.0.0：

{"overrides": {"bar": {"foo": "1.0.0"}}
}

鍵可以嵌套到任意長度。僅當 foo 是 bar 的子包并且 bar 是 baz 的子包時，才覆蓋 foo：

{"overrides": {"baz": {"bar": {"foo": "1.0.0"}}}

覆蓋的鍵還可以包含版本或版本范圍。僅當 foo 是 bar@2.0.0 的子包時，將 foo 覆蓋為 1.0.0：

{"overrides": {"bar@2.0.0": {"foo": "1.0.0"}}
}

除非依賴項和覆蓋本身具有相同的規范，否則你不能為你直接依賴的包設置覆蓋。為了讓這種限制更容易處理，覆蓋可以定義為對直接依賴項的規范引用，通過在你希望版本匹配的包名前添加 $ ：

{"dependencies": {"foo": "^1.0.0"},"overrides": {// 錯誤，將拋出 OVERRIDE 錯誤// "foo": "^2.0.0"// 正確，規范匹配，因此允許覆蓋// "foo": "^1.0.0"// 最佳，覆蓋定義為對依賴項的引用"foo": "$foo",// 被引用的包不需要與被覆蓋的包相同"bar": "$foo"}
}

27. engines（引擎）

你可以指定包兼容的 Node.js 版本：

{"engines": {"node": ">=0.10.3 <15"}
}

與依賴項類似，如果你不指定版本（或者指定 * 作為版本），那么任何版本的 Node.js 都可以使用。

你還可以使用 engines 字段指定能夠正確安裝你程序的 npm 版本。例如：

{"engines": {"npm": "~1.0.20"}
}

除非用戶設置了engine-strict?配置標志，否則該字段僅為建議用途，當你的包作為依賴項安裝時只會產生警告。

28. os（操作系統）

你可以指定模塊運行在哪些操作系統上：

{"os": ["darwin", "linux"]
}

你也可以阻止特定操作系統，只需在阻止的操作系統前加！

{"os": ["!win32"]
}

主機操作系統通過 process.platform 確定。

你可以同時阻止和允許某個操作系統，盡管這沒有什么意義。

29. cpu（CPU 架構）

如果你的代碼只能在某些 CPU 架構上運行，你可以指定這些架構：

{"cpu": ["x64", "ia32"]
}

與 os 選項類似，你也可以阻止某些架構：

{"cpu": ["!arm", "!mips"]
}

主機架構通過 process.arch 確定。

30. private（私有）

如果你在 package.json 中設置 "private": true，npm 將拒絕發布該包。

這是防止私有倉庫意外發布的方式。如果你希望確保某個包只發布到特定的注冊表（例如，內部注冊表），請使用下面描述的 publishConfig 字典，在發布時覆蓋 registry 配置參數。

31. publishConfig（發布配置）

這是發布時使用的一組配置值。如果你希望設置標記、注冊表或訪問權限，這特別方便。你可以確保給定的包不會標記為 "latest"，不會發布到全局公共注冊表，或者默認情況下范圍包是私有的。

請參閱 config 以查看可覆蓋的配置選項列表。

32. workspaces（工作區）

可選的 workspaces 字段是一個文件模式數組，描述了安裝客戶端應在本地文件系統中查找的每個工作區，這些工作區需要鏈接到頂級 node_modules 文件夾。

它可以描述要用作工作區的文件夾的直接路徑，也可以定義可以解析為這些文件夾的通配符。

在以下示例中，位于 ./packages 文件夾中的所有文件夾將被視為工作區，只要它們包含有效的 package.json 文件：

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

有關更多示例，請參閱 workspaces。

33. DEFAULT VALUES（默認值）

npm 會根據包內容默認一些值。

"scripts": {"start": "node server.js"}

如果包根目錄中有一個 server.js 文件，npm 會默認將啟動命令設置為 node server.js 。

"scripts":{"install": "node-gyp rebuild"}

如果包根目錄中有一個 binding.gyp 文件，并且你沒有定義 install 或 preinstall 腳本，npm 會默認使用 node-gyp 進行編譯。

"contributors": [...]

如果包根目錄中有一個 AUTHORS 文件，npm 會將每一行視為 Name <email> (url) 格式，其中 email 和 url 是可選的。以 # 開頭或空行的行將被忽略。