今天來看看前端的大管家 package.json 文件相關的配置,充分了解這些配置有助于我們提高開發的效率,規范我們的項目。文章內容較多,建議先收藏在學習!
在每個前端項目中,都有package.json文件,它是項目的配置文件,常見的配置有配置項目啟動、打包命令,聲明依賴包等。package.json文件是一個JSON對象,該對象的每一個成員就是當前項目的一項設置。package.json作為前端的大管家,到底有哪些配置和我們的日常開發密切相關?下面就來仔細剖析一下這個文件。
當我們搭建一個新項目時,往往腳手架就幫我們初始化好了一個package.jaon配置文件,它位于項目的根目錄中。當使用react腳手架(create-react-app)初始化一個項目時,其package.json文件內容如下:
{ "name": "my-app", "version": "0.1.0", "private": true, "dependencies": { "@testing-library/jest-dom": "^5.14.1", "@testing-library/react": "^11.2.7", "@testing-library/user-event": "^12.8.3", "react": "^17.0.2", "react-dom": "^17.0.2", "react-scripts": "4.0.3", "web-vitals": "^1.1.2" }, "scripts": { "start": "react-scripts start", "build": "react-scripts build", "test": "react-scripts test", "eject": "react-scripts eject" }, "eslintConfig": { "extends": [ "react-app", "react-app/jest" ] }, "browserslist": { "production": [ ">0.2%", "not dead", "not op_mini all" ], "development": [ "last 1 chrome version", "last 1 firefox version", "last 1 safari version" ] }}
當克隆一個新的項目到本地時,需要執行npm install(yarn install)命令來安裝項目所需的依賴文件。當執行該命令時,就會根據 package.json 文件中的配置信息來自動下載所需的模塊,也就是配置項目所需的運行和開發環境。
package.json 常見配置項如下:
package.json中最重要的兩個字段就是name和version,它們都是必須的,如果沒有,就無法正常執行npm install命令。npm規定package.json文件是由名稱和版本號作為唯一標識符的。
name很容易理解,就是項目的名稱,它是一個字符串。在給name字段命名時,需要注意以下幾點:
如果npm包上有對應的包,則會顯示包的詳細信息:
實際上,我們平時開發的很多項目并不會發布在npm上,所以這個名稱是否標準可能就不是那么重要,它不會影響項目的正常運行。如果需要發布在npm上,name字段一定要符合要求。
version字段表示該項目包的版本號,它是一個字符串。在每次項目改動后,即將發布時,都要同步的去更改項目的版本號。版本號的使用規范如下:
可以通過以下命令來查看npm包的版本信息,以react為例:
// 查看最新版本npm view react version// 查看所有版本npm view react versions
當執行第二條命令時,結果如下:
package.jaon中有五個和項目包描述信息相關的配置字段,下面就分別來看看這些字段的含義。
description字段用來描述這個項目包,它是一個字符串,可以讓其他開發者在 npm 的搜索中發現我們的項目包。
keywords字段是一個字符串數組,表示這個項目包的關鍵詞。和description一樣,都是用來增加項目包的曝光率的。下面是eslint包的描述和關鍵詞:
author顧名思義就是作者,表示該項目包的作者。它有兩種形式,一種是字符串格式:
"author": "CUGGZ <xxxxx@xx.com> (https://juejin.cn/user/3544481220801815)"
另一種是對象形式:
"author": { "name" : "CUGGZ", "email" : "xxxxx@xx.com", "url" : "https://juejin.cn/user/3544481220801815"}
contributors表示該項目包的貢獻者,和author不同的是,該字段是一個數組,包含所有的貢獻者,它同樣有兩種寫法:
"contributors": [ "CUGGZ0 <xxxxx@xx.com> (https://juejin.cn/user/3544481220801815)", "CUGGZ1 <xxxxx@xx.com> (https://juejin.cn/user/3544481220801815)" ]
"contributors": [ { "name" : "CUGGZ0", "email" : "xxxxx@xx.com", "url" : "https://juejin.cn/user/3544481220801815" }, { "name" : "CUGGZ1", "email" : "xxxxx@xx.com", "url" : "https://juejin.cn/user/3544481220801815" } ]
homepage就是項目的主頁地址了,它是一個字符串。
repository表示代碼的存放倉庫地址,通常有兩種書寫形式。第一種是字符串形式:
"repository": "https://github.com/facebook/react.git"
除此之外,還可以顯式地設置版本控制系統,這時就是對象的形式:
"repository": { "type": "git", "url": "https://github.com/facebook/react.git"}
bugs表示項目提交問題的地址,該字段是一個對象,可以添加一個提交問題的地址和反饋的郵箱:
"bugs": { "url" : "https://github.com/facebook/react/issues", "email" : "xxxxx@xx.com"}
最常見的bugs就是Github中的issues頁面,如上就是react的issues頁面地址。
通常情況下,我們的項目會依賴一個或者多個外部的依賴包,根據依賴包的不同用途,可以將他們配置在下面的五個屬性下:dependencies、devDependencies、peerDependencies、bundledDependencies、optionalDependencies 。下面就來看看每個屬性的含義。
dependencies字段中聲明的是項目的生產環境中所必須的依賴包。當使用 npm 或 yarn 安裝npm包時,該npm包會被自動插入到此配置項中:
npm install <PACKAGENAME>yarn add <PACKAGENAME>
當在安裝依賴時使用--save參數,也會將新安裝的npm包寫入dependencies屬性。
npm install --save <PACKAGENAME>
該字段的值是一個對象,該對象的各個成員,分別由模塊名和對應的版本要求組成,表示依賴的模塊及其版本范圍。
"dependencies": { "react": "^17.0.2", "react-dom": "^17.0.2", "react-scripts": "4.0.3",},
這里每一項配置都是一個鍵值對(key-value), key表示模塊名稱,value表示模塊的版本號。版本號遵循主版本號.次版本號.修訂號的格式規定:
需要注意,不要把測試或者過渡性的依賴放在dependencies,避免生產環境出現意外的問題。
devDependencies中聲明的是開發階段需要的依賴包,如Webpack、Eslint、Babel等,用于輔助開發。它們不同于 dependencies,因為它們只需安裝在開發設備上,而無需在生產環境中運行代碼。當打包上線時并不需要這些包,所以可以把這些依賴添加到 devDependencies 中,這些依賴依然會在本地指定 npm install 時被安裝和管理,但是不會被安裝到生產環境中。
當使用 npm 或 yarn 安裝軟件包時,指定以下參數后,新安裝的npm包會被自動插入到此列表中:
npm install --save-dev <PACKAGENAME>yarn add --dev <PACKAGENAME>
"devDependencies": { "autoprefixer": "^7.1.2", "babel-core": "^6.22.1"}
有些情況下,我們的項目和所依賴的模塊,都會同時依賴另一個模塊,但是所依賴的版本不一樣。比如,我們的項目依賴A模塊和B模塊的1.0版,而A模塊本身又依賴B模塊的2.0版。大多數情況下,這不是問題,B模塊的兩個版本可以并存,同時運行。但是,有一種情況,會出現問題,就是這種依賴關系將暴露給用戶。
最典型的場景就是插件,比如A模塊是B模塊的插件。用戶安裝的B模塊是1.0版本,但是A插件只能和2.0版本的B模塊一起使用。這時,用戶要是將1.0版本的B的實例傳給A,就會出現問題。因此,需要一種機制,在模板安裝的時候提醒用戶,如果A和B一起安裝,那么B必須是2.0模塊。
peerDependencies字段就是用來供插件指定其所需要的主工具的版本。
"name": "chai-as-promised","peerDependencies": { "chai": "1.x"}
上面代碼指定在安裝chai-as-promised模塊時,主程序chai必須一起安裝,而且chai的版本必須是1.x。如果項目指定的依賴是chai的2.0版本,就會報錯。
需要注意,從npm 3.0版開始,peerDependencies不再會默認安裝了。
如果需要在找不到包或者安裝包失敗時,npm仍然能夠繼續運行,則可以將該包放在optionalDependencies對象中,optionalDependencies對象中的包會覆蓋dependencies中同名的包,所以只需在一個地方進行設置即可。
需要注意,由于optionalDependencies中的依賴可能并為安裝成功,所以一定要做異常處理,否則當獲取這個依賴時,如果獲取不到就會報錯。
上面的幾個依賴相關的配置項都是一個對象,而bundledDependencies配置項是一個數組,數組里可以指定一些模塊,這些模塊將在這個包發布時被一起打包。
需要注意,這個字段數組中的值必須是在dependencies, devDependencies兩個里面聲明過的包才行。
當我們維護一些舊項目時,可能對npm包的版本或者Node版本有特殊要求,如果不滿足條件就可能無法將項目跑起來。為了讓項目開箱即用,可以在engines字段中說明具體的版本號:
"engines": { "node": ">=8.10.3 <12.13.0", "npm": ">=6.9.0"}
需要注意,engines只是起一個說明的作用,即使用戶安裝的版本不符合要求,也不影響依賴包的安裝。
scripts 是 package.json中內置的腳本入口,是key-value鍵值對配置,key為可運行的命令,可以通過 npm run 來執行命令。除了運行基本的scripts命令,還可以結合pre和post完成前置和后續操作。先來看一組scripts:
"scripts": { "dev": "node index.js", "predev": "node beforeIndex.js", "postdev": "node afterIndex.js"}
這三個js文件中都有一句console:
// index.jsconsole.log("scripts: index.js")// beforeIndex.jsconsole.log("scripts: before index.js")// afterIndex.jsconsole.log("scripts: after index.js")
當我們執行npm run dev命令時,輸出結果如下:
scripts: before index.jsscripts: index.jsscripts: after index.js
可以看到,三個命令都執行了,執行順序是predev→dev→postdev。如果scripts命令存在一定的先后關系,則可以使用這三個配置項,分別配置執行命令。
通過配置scripts屬性,可以定義一些常見的操作命令:
"scripts": { "dev": "webpack-dev-server --inline --progress --config build/webpack.dev.conf.js", "start": "npm run dev", "unit": "jest --config test/unit/jest.conf.js --coverage", "test": "npm run unit", "lint": "eslint --ext .js,.vue src test/unit", "build": "node build/build.js"}
這些腳本是命令行應用程序。可以通過調用 npm run XXX 或 yarn XXX 來運行它們,其中 XXX 是命令的名稱。例如:npm run dev。我們可以為命令使用任何的名稱,腳本也可以是任何操作。
使用好該字段可以大大的提升開發效率。
config字段用來配置scripts運行時的配置參數,如下所示:
"config": { "port": 3000}
如果運行npm run start,則port字段會映射到npm_package_config_port環境變量中:
console.log(process.env.npm_package_config_port) // 3000
用戶可以通過npm config set foo:port 3001 命令來重寫port的值。
下面來看看package.json中和文件以及目錄相關的屬性。
main 字段用來指定加載的入口文件,在 browser 和 Node 環境中都可以使用。如果我們將項目發布為npm包,那么當使用 require 導入npm包時,返回的就是main字段所列出的文件的module.exports 屬性。如果不指定該字段,默認是項目根目錄下的index.js。如果沒找到,就會報錯。
該字段的值是一個字符串:
"main": "./src/index.js",
browser字段可以定義 npm 包在 browser 環境下的入口文件。如果 npm 包只在 web 端使用,并且嚴禁在 server 端使用,使用 browser 來定義入口文件。
"browser": "./src/index.js"
module字段可以定義 npm 包的 ESM 規范的入口文件,browser 環境和 node 環境均可使用。如果 npm 包導出的是 ESM 規范的包,使用 module 來定義入口文件。
"module": "./src/index.mjs",
需要注意,*.js 文件是使用 commonJS 規范的語法(require('xxx')),*.mjs 是用 ESM 規范的語法(import 'xxx')。
上面三個的入口入口文件相關的配置是有差別的,特別是在不同的使用場景下。在Web環境中,如果使用loader加載ESM(ES module),那么這三個配置的加載順序是browser→module→main,如果使用require加載CommonJS模塊,則加載的順序為main→module→browser。
Webpack在進行項目構建時,有一個target選項,默認為Web,即構建Web應用。如果需要編譯一些同構項目,如node項目,則只需將webpack.config.js的target選項設置為node進行構建即可。如果再Node環境中加載CommonJS模塊,或者ESM,則只有main字段有效。
bin字段用來指定各個內部命令對應的可執行文件的位置:
"bin": { "someTool": "./bin/someTool.js"}
這里,someTool 命令對應的可執行文件為 bin 目錄下的 someTool.js,someTool.js會建立符號鏈接node_modules/.bin/someTool。由于node_modules/.bin/目錄會在運行時加入系統的PATH變量,因此在運行npm時,就可以不帶路徑,直接通過命令來調用這些腳本。因此,下面的寫法可以簡寫:
scripts: { start: './node_modules/bin/someTool.js build'}// 簡寫scripts: { start: 'someTool build'}
所有node_modules/.bin/目錄下的命令,都可以用npm run [命令]的格式運行。
上面的配置在package.json包中提供了一個映射到本地文件名的bin字段,之后npm包將鏈接這個文件到prefix/fix里面,以便全局引入。或者鏈接到本地的node_modules/.bin/文件中,以便在本項目中使用。
files配置是一個數組,用來描述當把npm包作為依賴包安裝時需要說明的文件列表。當npm包發布時,files指定的文件會被推送到npm服務器中,如果指定的是文件夾,那么該文件夾下面所有的文件都會被提交。
"files": [ "LICENSE", "Readme.md", "index.js", "lib/" ]
如果有不想提交的文件,可以在項目根目錄中新建一個.npmignore文件,并在其中說明不需要提交的文件,防止垃圾文件推送到npm上。這個文件的形式和.gitignore類似。寫在這個文件中的文件即便被寫在files屬性里也會被排除在外。比如可以在該文件中這樣寫:
node_modules.vscodebuild.DS_Store
man 命令是 Linux 中的幫助指令,通過該指令可以查看 Linux 中的指令幫助、配置文件幫助和編程幫助等信息。如果 node.js 模塊是一個全局的命令行工具,在 package.json 通過 man 屬性可以指定 man 命令查找的文檔地址:
"man": [ "./man/npm-access.1", "./man/npm-audit.1"]
man 字段可以指定一個或多個文件, 當執行man {包名}時, 會展現給用戶文檔內容。
需要注意:
對于上面的配置,可以使用以下命令來執行查看文檔:
man npm-accessman npm-audit
directories字段用來規范項目的目錄。node.js 模塊是基于 CommonJS 模塊化規范實現的,需要嚴格遵循 CommonJS 規范。模塊目錄下除了必須包含包項目描述文件 package.json 以外,還需要包含以下目錄:
在實際的項目目錄中,我們可能沒有按照這個規范進行命名,那么就可以在directories字段指定每個目錄對應的文件路徑:
"directories": { "bin": "./bin", "lib": "./lib", "doc": "./doc", "test" "./test", "man": "./man"},
這個屬性實際上沒有什么實際的作用,當然不排除未來會有什么比較有意義的用處。
下面來看看和npm項目包發布相關的配置。
private字段可以防止我們意外地將私有庫發布到npm服務器。只需要將該字段設置為true:
"private": true
preferGlobal字段表示當用戶不把該模塊安裝為全局模塊時,如果設置為true就會顯示警告。它并不會真正的防止用戶進行局部的安裝,只是對用戶進行提示,防止產生誤解:
"preferGlobal": true
publishConfig配置會在模塊發布時生效,用于設置發布時一些配置項的集合。如果不想模塊被默認標記為最新,或者不想發布到公共倉庫,可以在這里配置tag或倉庫地址。更詳細的配置可以參考 npm-config。
通常情況下,publishConfig會配合private來使用,如果只想讓模塊發布到特定npm倉庫,就可以這樣來配置:
"private": true,"publishConfig": { "tag": "1.1.0", "registry": "https://registry.npmjs.org/", "access": "public"}
os字段可以讓我們設置該npm包可以在什么操作系統使用,不能再什么操作系統使用。如果我們希望開發的npm包只運行在linux,為了避免出現不必要的異常,建議使用Windows系統的用戶不要安裝它,這時就可以使用os配置:
"os" ["linux"] // 適用的操作系統"os" ["!win32"] // 禁用的操作系統
該配置和OS配置類似,用CPU可以更準確的限制用戶的安裝環境:
"cpu" ["x64", "AMD64"] // 適用的cpu"cpu" ["!arm", "!mips"] // 禁用的cpu
可以看到,黑名單和白名單的區別就是,黑名單在前面加了一個“!”。
license 字段用于指定軟件的開源協議,開源協議表述了其他人獲得代碼后擁有的權利,可以對代碼進行何種操作,何種操作又是被禁止的。常見的協議如下:
可以這樣來聲明該字段:
"license": "MIT"
package.json 文件還可以承載命令特有的配置,例如 Babel、ESLint 等。它們每個都有特有的屬性,例如 eslintConfig、babel 等。它們是命令特有的,可以在相應的命令/項目文檔中找到如何使用它們。下面來看幾個常用的第三方配置項。
typings字段用來指定TypeScript的入口文件:
"typings": "types/index.d.ts",
該字段的作用和main配置相同。
eslint的配置可以寫在單獨的配置文件.eslintrc.json 中,也可以寫在package.json文件的eslintConfig配置項中。
"eslintConfig": { "root": true, "env": { "node": true }, "extends": [ "plugin:vue/essential", "eslint:recommended" ], "rules": {}, "parserOptions": { "parser": "babel-eslint" },}
babel用來指定Babel的編譯配置,代碼如下:
"babel": { "presets": ["@babel/preset-env"], "plugins": [...]}
使用該字段可以讓 npm 上所有的文件都開啟 cdn 服務,該CND服務由unpkg提供:
"unpkg": "dist/vue.js"
lint-staged是一個在Git暫存文件上運行linters的工具,配置后每次修改一個文件即可給所有文件執行一次lint檢查,通常配合gitHooks一起使用。
"lint-staged": { "*.js": [ "eslint --fix", "git add" ]}
使用lint-staged時,每次提交代碼只會檢查當前改動的文件。
gitHooks用來定義一個鉤子,在提交(commit)之前執行ESlint檢查。在執行lint命令后,會自動修復暫存區的文件。修復之后的文件并不會存儲在暫存區,所以需要用git add命令將修復后的文件重新加入暫存區。在執行pre-commit命令之后,如果沒有錯誤,就會執行git commit命令:
"gitHooks": { "pre-commit": "lint-staged"}
這里就是配合上面的lint-staged來進行代碼的檢查操作。
browserslist字段用來告知支持哪些瀏覽器及版本。Babel、Autoprefixer 和其他工具會用到它,以將所需的 polyfill 和 fallback 添加到目標瀏覽器。比如最上面的例子中的該字段值:
"browserslist": { "production": [ ">0.2%", "not dead", "not op_mini all" ], "development": [ "last 1 chrome version", "last 1 firefox version", "last 1 safari version" ]}
這里指定了一個對象,里面定義了生產環境和開發環境的瀏覽器要求。上面的development就是指定開發環境中支持最后一個版本的chrome、Firefox、safari瀏覽器。這個屬性是不同的前端工具之間共用目標瀏覽器和 node 版本的配置工具,被很多前端工具使用,比如Babel、Autoprefixer等。
本文鏈接:http://www.tebozhan.com/showinfo-26-10411-0.htmlPackage.json 配置完全解讀,充分了解這些配置有助于我們提高開發的效率
聲明:本網頁內容旨在傳播知識,若有侵權等問題請及時與本網聯系,我們將在第一時間刪除處理。郵件:2376512515@qq.com
上一篇: Java中日志記錄不完整或不規范,難以進行問題排查和系統監控
下一篇: 增強現實正在改變市場營銷