npm是前端開發人員廣泛使用的套件管理工具，專案中透過package.json來管理專案中所依賴的npm套件的配置。 package.json就是一個json文件，除了能夠描述專案的套件依賴外，允許我們使用「語意化版本規則」指明你專案依賴套件的版本，讓你的建置更好地與其他開發者分享，便於重複使用。 本文主要從最近的實踐出發，結合最新的npm和node的版本，介紹一下package.json中一些常見的配置以及如何寫一個規範的package.json
在nodejs專案中，package.json是管理其依賴的配置文件，通常我們在初始化一個nodejs專案的時候會通過：
npm init
然後在你的目錄下會產生3個目錄/文件， node_modules, package.json和package.lock.json。其中package.json的內容為：
{
"name": "Your project name",
"version": "1.0.0",
"description": "Your project description",
"main": "app.js",
"scripts": {
"test": "echo "Error: no test specified" && exit 1",
},
"author": "Author name",
"license": "ISC",
"dependencies": {
"dependency1": "^1.4.0",
"dependency2": "^1.5.2"
}
}上述可以看出，package.json中包含了項目本身的元資料,以及項目的子依賴資訊(例如dependicies等)。
我們發現在npm init的時候，不僅產生了package.json文件，也產生了package-lock.json文件。那為什麼存在package.json的清空下，還需要產生package-lock.json檔案呢。本質上package-lock.json檔案是為了鎖版本，在package.json中指定的子npm套件例如：react: "^16.0.0"，在實際安裝中，只要高於react的版本都滿足package.json的要求。這樣就使得根據同一個package.json文件，兩次安裝的子依賴版本不能保證一致。
而package-lock檔案如下所示，子依賴dependency1就詳細的指定了其版本。起到lock版本的作用。
{
"name": "Your project name",
"version": "1.0.0",
"lockfileVersion": 1,
"requires": true,
"dependencies": {
"dependency1": {
"version": "1.4.0",
"resolved":
"https://registry.npmjs.org/dependency1/-/dependency1-1.4.0.tgz",
"integrity":
"sha512-a+UqTh4kgZg/SlGvfbzDHpgRu7AAQOmmqRHJnxhRZICKFUT91brVhNNt58CMWU9PsBbv3PDCZUHbVxuDiH2mtA=="
},
"dependency2": {
"version": "1.5.2",
"resolved":
"https://registry.npmjs.org/dependency2/-/dependency2-1.5.2.tgz",
"integrity":
"sha512-WOn21V8AhyE1QqVfPIVxe3tupJacq1xGkPTB4iagT6o+P2cAgEOOwIxMftr4+ZCTI6d551ij9j61DFr0nsP2uQ=="
}
}
}本章來聊聊package.json中常用的配置屬性，形如name，version等屬性太簡單，不一一介紹。本章主要介紹一下script、bin和workspaces屬性。
在npm中使用script標籤來定義腳本，每當制定npm run的時候，就會自動建立shell腳本，這裡需要注意的是，npm run新建的這個Shell，會將本地目錄的node_modules/.bin子目錄加入PATH變數。
這意味著，目前目錄的node_modules/.bin子目錄裡面的所有腳本，都可以直接用腳本名稱調用，而不必加上路徑。例如，目前專案的依賴裡面有esbuild，只要直接寫esbuild xxx 就可以了。
{
// ...
"scripts": {
"build": "esbuild index.js",
}
} {
// ...
"scripts": {
"build": "./node_modules/.bin/esbuild index.js"
}
}上面兩種寫法是等價的。
bin屬性用來將可執行檔載入到全域環境中，指定了bin欄位的npm包，一旦在全域安裝，就會載入到全域環境中，可以透過別名來執行該檔。
例如@bytepack/cli的npm套件：
"bin": {
"bytepack": "./bin/index.js"
},一旦在全域安裝了@bytepack/cli，就可以直接透過bytepack來執行對應的命令，例如
bytepack -v //顯示1.11.0
如果非全域安裝，那麼會自動連線到專案的node_module/.bin目錄中。與前面介紹的script標籤所說的一致，可以直接用別名來使用。
在專案過大的時候，最近越來越流行monorepo。提到monorepo就繞不看workspaces，早期我們會用yarn workspaces，現在npm官方也支持了workspaces. workspaces解決了本地文件系統中如何在一個頂層root package下管理多個子packages的問題，在workspaces聲明目錄下的package會軟鏈到最上層root package的node_modules中。
直接以官網的例子來說明：
{
"name": "my-project",
"workspaces": [
"packages/a"
]
}在一個npm套件名為my-project的npm套件中，存在著workspaces配置的目錄。
. +-- package.json +-- index.js `-- packages +-- a | `-- package.json
並且該最上層的名為my-project的root包，有packages/a子包。此時，我們如果npm install,那麼在root package中node_modules中安裝的npm包a，指向的是本地的package/a.
. +-- node_modules | `-- packages/a -> ../packages/a +-- package-lock.json +-- package.json `-- packages +-- a | `-- package.json
上述的
-- packages/a -> ../packages/a
指的就是從node_modules中a連結到本地npm包的軟鏈
常見的環境，基本上分為瀏覽器browser和node環境兩大類，接下來我們來看看package.json中，跟環境相關的設定屬性。環境的定義可以簡單理解如下：
js的模組化規範包含了commonjs、CMD、UMD、AMD和ES module等，最早先在node中支持的僅僅是commonjs字段，但是從node13.2.0開始後，node正式支持了ES module規範，在package.json中可以透過type欄位來宣告npm套件所遵循的模組化規格。
//package.json
{
name: "some package",
type: "module"||"commonjs"
}要注意的是：
不指定type的時候，type的預設值是commonjs，但建議npm套件都指定一下type
當type欄位指定值為module則採用ESModule規格
當type欄位指定時，目錄下的所有.js後綴結尾的文件，都遵循type所指定的模組化規範
除了type可以指定模組化規範外，透過文件的後綴來指定文件所遵循的模組化規範，以.mjs結尾的文件就是使用的ESModule規範，以.cjs結尾的遵循的是commonjs規格
除了type外，package.json中還有main,module和browser 3個欄位來定義npm套件的入口檔案。
我們來看這3個欄位的使用場景，以及同時存在這3個欄位時的優先權。我們假設有一個npm套件為demo1,
----- dist |-- index.browser.js |-- index.browser.mjs |-- index.js |-- index.mjs
其package.json中同時指定了main,module和browser這3個字段，
"main": "dist/index.js", // main
"module": "dist/index.mjs", // module
// browser 可定義成和main/module 欄位一一對應的映射對象，也可以直接定義為字串"browser": {
"./dist/index.js": "./dist/index.browser.js", // browser+cjs
"./dist/index.mjs": "./dist/index.browser.mjs" // browser+mjs
},
// "browser": "./dist/index.browser.js" // browser預設建置和使用，例如我們在專案中引用這個npm套件：
import demo from 'demo'
透過建置工具建立上述程式碼後，模組的載入循序為：
browser+mjs > module > browser+cjs > main
這個載入順序是大部分建置工具預設的載入順序，例如webapck、esbuild等等。可以透過對應的配置修改這個載入順序，不過大部分場景，我們還是會遵循預設的載入順序。
如果在package.json中定義了exports字段，那麼這個字段所定義的內容就是該npm包的真實和全部的導出，優先級會高於main和file等字段。
舉例來說：
{
"name": "pkg",
"exports": {
".": "./main.mjs",
"./foo": "./foo.js"
}
} import { something } from "pkg"; // from "pkg/main.mjs" const { something } = require("pkg/foo"); // require("pkg/foo.js")從上述的例子來看，exports可以定義不同path的匯出。如果存在exports後，以前正常生效的file目錄到處會失效，例如require('pkg/package.json')，因為在exports中沒有指定，就會報錯。
exports還有一個最大的特點，就是條件引用，例如我們可以根據不同的引用方式或模組化類型，來指定npm套件引用不同的入口檔案。
// package.json
{
"name":"pkg",
"main": "./main-require.cjs",
"exports": {
"import": "./main-module.js",
"require": "./main-require.cjs"
},
"type": "module"
}上述的例子中，如果我們透過
const p = require('pkg')引用的就是"./main-require.cjs"。
如果透過：
import p from 'pkg'
引用的就是"./main-module.js"
最後要注意的是：如果存在exports屬性，exports屬性不僅優先權高於main，同時也高於module和browser欄位。
package.json中跟依賴相關的配置屬性包含了dependencies、devDependencies、peerDependencies和peerDependenciesMeta等。
dependencies是專案的依賴，而devDependencies是開發所需的模組，所以我們可以在開發過程中所需的安裝上去，來提高我們的開發效率。這裡需要注意的時，在自己的專案中盡量的規範使用，形如webpack、babel等是開發依賴，而不是專案本身的依賴，不要放在dependencies中。
dependencies除了dependencies和devDependencies，本文重點介紹的是peerDependencies和peerDependenciesMeta。
peerDependencies是package.json中的依賴項,可以解決核心庫被下載多次，以及統一核心庫版本的問題。
//package/pkg ----- node_modules |-- npm-a -> 依賴了react,react-dom |-- npm-b -> 依賴了react,react-dom |-- index.js
例如上述的例子中如果子npm包a,b都以來了react和react-dom,此時如果我們在子npm包a,b的package.json中聲明了PeerDependicies後，相應的依賴就不會重新安裝。
需要注意的有兩點：
看到「Meta」就有元資料的意思，這裡的peerDependenciesMeta就是詳細修飾了peerDependicies，例如在react-redux這個npm包中的package.json中有這麼一段：
"peerDependencies": {
"react": "^16.8.3 || ^17 || ^18"
},
"peerDependenciesMeta": {
"react-dom": {
"optional": true
},
"react-native": {
"optional": true
}
}這裡指定了"react-dom","react-native"在peerDependenciesMeta中，且為可選項，因此如果專案中檢測沒有安裝"react-dom"和"react-native"都不會報錯。
值得注意的是，透過peerDependenciesMeta我們確實是取消了限制，但是這裡經常存在非A即B的場景，比如上述例子中，我們需要的是“react-dom”和"react-native"需要安裝一個，但是實際上透過上述的聲明，我們實現不了這種提示。
package.json中也存在許多三方屬性，例如tsc中使用的types、構建工具中使用的sideEffects,git中使用的husky，eslint使用的eslintIgnore，這些擴展的配置，針對特定的擴展開發工具是有意義的這裡不一一舉例。