小米官宣：2023年上半年出貨量中國第一！
今日早間，小米電視官方微博帶來消息，稱2023年小米電視上半年出貨量達到了中國第一，同時還表示小米電視的巨屏風暴即將開始。“公布一個好消息2023年#小米電視上半年出貨量中國
今天我們就來講講「package.json」。
還有很多同學說，f_cli[1]啥時候開源。這里簡單說一嘴，因為f_cli現在只適配了針對vite+react的模板，然后我想著想把vite+vue/webpack+react/vue/rsPack+vue/react最起碼再適配1-2個后，才有開源計劃。
package.json 是JS/TS項目的說明書和指導手冊
按照功能來分類，package.json具有如下的功能：(有些功能是可以相互配合使用的)
一個成熟的語言，不僅僅需要在語言層面功能完備，還體現在構建大型項目時是否具有低成本的依賴管理能力。
現在有許多用于依賴管理的工具，比如 Java 的 Maven，Python 的 pip，JavaScript 的 npm/pnpm /yarn，以及 Rust 的 Cargo。
每個包管理器都需要一種方式來跟蹤在「當前項目中應該使用哪些版本的哪些軟件包」。通常，會創建一個文件，將這些「依賴關系映射到它們對應的版本」上。比如，
我們今天的主角 -package.json的主要作用是「跟蹤項目中所需的所有依賴關系」。當運行 JS 包管理器上的 install 命令時，它將安裝在 package.json 文件中提到的軟件包的相應版本。
這點大家都很熟，在現在前端開發中，尤其在SPA模式開發下，我們通常會使用打包工具Vite/Webpack/rsPack分別對開發模式和生產模式進行區分。要想實現上述操作。我們就需要在一個地方定義一些操作:執行命令，并且能夠在通過npm cli命令行執行這些「操作」。
而這就是package.json中scripts的用途。我們可以定義很多操作然后執行諸如dev/build/prepare/postinstall等命令。
這個是利用npm的生命周期做一些資源整合的事情。這個我們會另寫一篇文章。這里也不再多講。
在如何在 npm 上發布二進制文件？中，我們同樣有package.json，它既不是用于「依賴管理」也不是用于定義項目命令，而是通過一些字段的配置來說明包的名稱和版本信息，以及該包被用于那些操作系統和系統架構。
也就是說，
package.json還可以存儲必要的包的元數據。
我們可以使用 npm init 命令在任意我們想創建前端項目的文件夾中創建一個 package.json 文件。當我們運行該命令時，它會詢問我們一系列的問題，我們輸入的所有答案都會顯示在我們的 package.json 文件中。
圖片
當我們填入我們想要的信息后，就會在項目的根目錄下創建一個package.json文件。
{ "name": "front789", "version": "1.0.0", "description": "專注于前端開發技術Rust及AI應用知識分享的Coder", "main": "index.js", "scripts": { "test": "vitest" }, "repository": { "type": "git", "url": "https://xxx/xxx" }, "keywords": ["前端開發", "rust", "ai"], "author": "front789 (https://xxx/xx)", "license": "MIT"}當然我們也可以采用手動方式在項目根目錄下創建一個package.json并填入必要的信息
如果大家看過package.json的官網[2]的話，會發現有很多屬性，并用它使用場景五花八門。
而今天我們也不打算把這些屬性都過一遍，我會有選擇的挑選一些對我們平時開發有用的屬性來講。
name 字段用于標識軟件包。
{ "name": "my-project"}在 package.json 文件中，name和version是「強制」的，它們一起被認為是唯一的。例如，如果name是 f_cli，version是 0.1.0，那么就假定f_cli@0.1.0是唯一的，不指代任何其他軟件包。
軟件包name也是有一定的限制的。
?
它需要符合^(?:(?:@(?:[a-z0-9-*~][a-z0-9-*._~]*)?/[a-z0-9-._~])|[a-z0-9-~])[a-z0-9-._~]*$正則規則
?
軟件包名稱也可以是作用域(scope)的。例如，軟件包的名稱可以是@front/f_cli。這是@organization/package 的形式。但是這種形式時候需要花錢的。
如果將包發布到 npmjs，則 name 屬性是必需的并且必須是唯一的。如果使用和 npmjs已經存在的名稱發布包，將收到錯誤。
如果不將包發布到npmjs,那么項目的name字段就沒有那么多要求。
{ "version": "1.1.0",}version 字段也是用于標識軟件包的鍵。通常，此版本號必須是可由 node-semver[3] 解析的。
「語義化版本控制」（Semantic Versioning，SemVer）是一組用于版本控制的規則，以便版本號的更改表明軟件包中的變化類型。
版本號以 MAJOR.MINOR.PATCH 的形式編寫
例如，如果軟件包的當前版本為 1.0.9：
description 字段簡要描述了「軟件包的功能」。它對于 SEO 也很有用，因為它幫助其他人可以在npmjs.com 網站上找到我們的軟件包。當用戶在npmjs.com搜索包時，此字符串用于幫助顯示包。
就像我們f_li_darwin_arm64的包有如下的配置信息。
圖片
當我們在npmjs中按照description搜索時也會返回對應的結果。
圖片
即使我們沒有將其發布到npmjs，它也可以用作項目的說明書,來說明該項目的性質和功能。起到一個「高屋建瓴」的作用。
{ "keywords": ["f_cli", "MACOS_Intel64"]}keywords 字段是一個「字符串數組」，與 description 類似，keywords 字段也用于 SEO。該字段由 npmjs編制索引，用于幫助在有人搜索包時找到包。數組中的每個值都是與我們的包關聯的一個關鍵字。
圖片
如果我們不發布到npmjs，則此字段沒有多大用處，可以隨意省略它。
{ "homepage": "https://github.com/owner/project#readme"}通常，我們會在此字段中鏈接到項目的網站地址。或者，我們還可以指向項目的 README 或文檔。
{ "bugs": { "url": "https://github.com/owner/project/issues", "email": "project@hostname.com" }}當別人使用了我們的包，在遇到問題后可以依據這個字段提供的url和email來提出問題，并嘗試在需要的地方尋找解決方案。
如果我們不想提供支持電子郵件，我們可以直接將 URL 分配給 bugs 屬性。
{ "bugs": "https://github.com/owner/project/issues",}{ "license":"MIT"}license 是一個重要的字段，因為它向使用包的用戶描述了我們在使用此軟件包時設置的「權限」和「限制」。理想情況下，對于開源軟件包，許可證應該是 OSI 批準[4]的許可證之一。
下面是我們常見的OSI軟件開源協議。
許可證 | 版本 | 主要特點 |
GNU通用公共許可證（GPL） | 2.0 | 允許使用、修改、復制和分發軟件，要求在修改后的軟件中保持相同的GPL許可協議。 |
3.0 | 強調數字版權管理（DRM）和專利許可，以保障開源軟件的自由性和用戶權益。 | |
MIT許可證 | - | 允許幾乎所有情況下自由使用、修改、復制和分發軟件，只要在軟件和相關文檔中包含原許可協議和版權聲明。 |
Apache許可證 2.0 | - | 允許使用、修改、復制和分發軟件，要求在分發時保留原始許可協議和版權聲明，修改后的代碼必須以某種形式標明更改。 |
BSD許可證 | 2-Clause | 允許自由使用、修改、復制和分發軟件，要求在分發時保留原始許可協議和版權聲明。 |
3-Clause | 在2-Clause BSD License的基礎上增加了對使用軟件名稱、作者名稱或衍生品的宣傳中的責任免除條款。 | |
GNU寬通用公共許可證（LGPL） | 2.1 | 允許在自由和開源項目中使用該軟件，并在修改后的庫中使用不同的許可協議。 |
3.0 | 強調數字版權管理（DRM）和專利許可，適用于開源項目，并在修改后的庫中使用不同的許可協議。 |
如果我們不希望在任何條件下向軟件包的用戶授予任何權限，可以將此字段設置為 UNLICENSED。
如果這個項目是我們公司的項目，并且也不準備開源，應該將 package.json 文件中的 private 字段設置為 true，以防止意外發布軟件包。
author 字段用于提供有關軟件包開發者的信息。它包括一個name，以及一個可選的email和 url 字段。
以下是一個示例：
{ "name": "front789", "email": "xx@gmial.com", "url": "https://xx.io"}所有這些信息也可以縮小成以下格式的單個字符串：
{ "author": "Name <Email> (Site)"}例如，我們可以使用此格式指定與上述相同的作者：
{ "author": "front789 <xx@gmial.com> (https://xx.io)"}與 author 字段類似，contributors 字段提供有關軟件包開發者的信息。它包含一個作者數組。
files 字段是一個「文件模式數組」，描述當「我們的包作為依賴項安裝時要包含的文件」。
文件模式遵循與.gitignore 類似的語法。唯一的區別是在.gitignore 中指定的文件被排除在外，而這些文件被包括在內。我們還可以使用像*和**/*這樣的 glob 模式，就像在.gitignore 文件中一樣。
如果未特別指定，則 files 字段默認為["*"]。
我們可以在包的根目錄或子目錄中提供 .npmignore 文件，這將防止包含文件。 .npmignore 文件的工作方式與 .gitignore 類似。
一些特殊的文件和目錄也會被包含，無論它們是否存在于 files 數組中。
其中README 和 LICENSE/LICENCE 文件可以具有任何擴展名。
{ "main": "src/index.js",}main 字段是 package.json 的「功能屬性」。這定義了項目的入口點，通常也是用于啟動項目的文件。
如果我們的軟件包（假設其名稱為 front789）由用戶安裝，那么當用戶執行 require('front789') 時,則將返回主模塊的導出對象。
這通常是項目根目錄中的 index.js 文件，但它可以是我們選擇用作包的主入口的任何文件。
如果未設置 main，則默認為包根文件夾中的 index.js
該字段在Node12+有另外的替代方案 - exports。
圖片
我們可以使用 exports 字段定義軟件包的入口點，作為 main 字段的替代方案。與 main 不同，exports 允許我們定義子路徑導出和條件導出。
例如，我們可以使用以下 exports 屬性導出項目的 submodule.js 文件：
{ "exports": { ".": "./index.js", "./submodule.js": "./src/submodule.js" }}還可以條件導出 - 具體取決于軟件包的使用者是使用 require 還是 import。
{ "exports": { "import": "./index-module.js", "require": "./index-require.cjs" }, "type": "module"}條件導出通常用于 ESM 軟件包，以確保向后兼容性，因為 import 關鍵字只能在 ESM 中使用。
此字段描述了當前軟件包中的.js 文件應該被視為 ESM 還是 commonjs。我們可以為 ESM 設置module類型，并為非ESM 軟件包設置 commonjs。
此外，我們還可以明確指定文件是否應該解釋為 ESM 或 commonjs，使用.mjs 擴展名表示 ESM，.cjs擴展名表示 commonjs 文件。
{ "type": "module"}此字段用于表示軟件包是否應在瀏覽器中使用，而不是在 Node.js 項目中使用，以取代 main。當我們的軟件包使用像 window 這樣的瀏覽器API，在 Node.js 環境中不可用時，就會使用它。
這個我們很熟，在如何在 npm 上發布二進制文件？中，我們在定義主包時，就使用了bin字段。
bin 字段，該字段是「命令名」到「本地文件名」的映射。
在某些情況下，npm 軟件包需要安裝到 PATH 中，以便它們可以在任何目錄中直接由操作系統運行。bin 字段指定這些類似可執行文件的文件。
當此軟件包「全局安裝」時，該文件將鏈接到全局 bins 目錄內，或者將創建一個 cmd（Windows 命令文件）來執行 bin 字段中的指定文件，因此可用于由 name 或 name.cmd（在 Windows PowerShell 上）運行。
當我們在 bin 屬性中有以下配置。
{ "bin": { "c1": "./r1.js", "c2": "./r2.js" }}在全局安裝此軟件包（使用 npm install -g）后，我們將能夠直接從終端運行 c1 和 c2 等命令。
bin 屬性提到的文件，都以 shebang語法 #!/usr/bin/env node 開頭，否則我們的操作系統將不會意識到該文件應在 Node.js 環境中運行。
shebang是一種在Unix/Linux系統中用于「指定腳本解釋器的約定」。在Node.js中，也可以使用shebang來指定Node.js作為腳本的解釋器。在腳本文件的開頭，添加類似于#!/usr/bin/env node的行，告訴操作系統使用Node.js來解釋執行該腳本。
Node.js的shebang行告訴操作系統找到Node.js解釋器并使用它來執行腳本。這使得腳本可以作為可執行文件直接運行，而不必在命令行中顯式調用Node.js。
還記得f_cli的npm版本嗎。
我們在package.json中的bin字段定義f_cli_f和bin/cli直接的關系
圖片
并且在bin/cli中使用shebang指定node.js作為腳本解釋器。
圖片
該字段來記錄項目代碼所在的地址。該字段是一個對象，它定義了源代碼所在的 url，以及它使用的版本控制系統類型。對于開源項目，大部分都是GitHub，以 Git 作為版本控制系統。
{ "repository": { "type": "git", "url": "https://github.com/xxx/docs.git" }}script 字段是 package.json 中另一個「功能性元數據」
scripts 屬性是一個包含我們可以使用 npm CLI 運行的腳本命令的「字典」。其鍵是我們可以使用 npm run <scriptName> 運行的腳本，值是實際運行的命令。這些通常是終端命令，我們將其放入腳本字段中，以便我們可以記錄它們并輕松地重用它們。
我們還可以指定在軟件包生命周期的不同時間運行的腳本。例如，我們可以添加一個 prepublish 腳本，在軟件包發布之前運行（當我們運行 npm publish 時）。
這是一個比較大的主題，我們打算另起一篇，詳細介紹一下
{ "dependencies": { "A": "^4.16.4", "B": "~1.7.4" }}此處列出了我們的項目使用的所有依賴項。使用 npm cli 安裝軟件包時(npm install xxx@1.0.1)，會將其下載到我們的 node_modules/ 文件夾中，并將添加到我們的依賴項屬性中，并注明軟件包的名稱(xxx)和安裝的版本(1.0.1)。
dependencies字段是一個對象，以包名稱作為鍵，以版本或版本范圍作為值。從這個列表中，npm 知道當 npm install 在目錄中運行時要獲取和安裝哪些包（以及什么版本）。 package.json 的 dependency 字段是項目的核心，它定義了項目所需的外部包。
我們在dependencies中看到的脫字號 (^) 和波形符 (~) 是 SemVer[5] 中定義的版本范圍的表示法。
在語義版本控制中,版本號由三個數字組成,格式如下:
`主版本號.次版本號.修訂號`~1.2.3 表示 >=1.2.3 并且 <1.3.0 的最新版本
所以簡單來說:
與 dependencies 字段類似，但適用于僅在開發期間需要而在生產中不需要的包。
例如，在前端項目中我們使用eslint/oxlint進行代碼規范處理，一旦應用程序部署并投入生產，我們就不再使用它。devDependencies 屬性讓我們明確指出生產中不需要哪些依賴項。
我們可以使用npm install --save-dev <package>安裝指定的包,并且將相關的包信息記錄到dependencies中。
但是呢，由于我們項目開發時，可以隨意引入外部包，有的同學也會將在開會環境中起作用的包安裝到dependencies中。這樣，無形中增加我們生產環境的外部資源容量。
為了解決這個問題，我們可以在生產環境中安裝應用程序時，我們可以使用 npm install --production 僅安裝 package.json 的 dependency 字段中列出的內容。
peerDependencies 字段用于指定「一個包依賴于其他包的特定版本」。這是為了解決一種情況：當一個包（插件或庫）希望與另一個包協同工作，但不希望將其作為直接依賴項安裝。
當某個包 A 聲明了它的 peerDependencies，它實際上是在聲明：“我期望運行時環境中會有某個包 B 的特定版本，但我不會直接將 B 包添加為我的依賴項，而是期望它由運行時環境或其他上層的包提供。”
以下是一個簡單的示例，展示了 peerDependencies 的用法：
{ "name": "my-package", "version": "1.0.0", "peerDependencies": { "some-other-package": "^2.0.0" }}在這個例子中，my-package 依賴于 some-other-package 的版本，但它并沒有將其添加到 dependencies 中。相反，它期望運行時環境或上層的包會提供符合 ^2.0.0 版本要求的 some-other-package。
使用 peerDependencies 的主要目的是「確保在整個項目中使用相同版本的某個包，以防止出現不一致的依賴關系導致的問題」。這有助于確保包之間的協同工作，并降低由于版本不一致而引起的潛在問題。
peerDependenciesMeta 字段用于提供 peerDependencies 的額外元數據信息,以幫助管理 peerDependencies。
它是一個對象,key 是 peerDependencies 的名字,value 是關于這個依賴的額外信息。
比如:
{ "peerDependencies": { "react": ">=16.8.0" }, "peerDependenciesMeta": { "react": { "optional": true } } }這里對 react 這個 peerDependency 提供了額外的元數據:optional: true。
這個 optional 鍵指明這個 peerDependency 是可選的,如果使用者沒有顯式安裝它,也不會觸發警告。
這比直接把依賴設置為 optionalDependencies 要好,因為這樣所有的 peerDependency 都聚集在 peerDependencies 字段中,而不會分散在兩個地方。
peerDependenciesMeta 還可以用于提供其他元數據,比如說明、地位等,以便更好地幫助使用者理解和管理 peerDependencies。
bundleDependencies字段用于指定將哪些依賴包打包到最終的發布包中。
比如:
{ "name": "example-package", "version": "1.0.0", "bundledDependencies": [ "lodash", "moment" ]}這意味著當這個包被發布時,lodash和moment這兩個依賴會被打包到發布包中,而不是作為外部依賴被安裝。
bundleDependencies的常見使用場景包括:
使用bundleDependencies需要注意:
所以需要根據實際情況權衡利弊來決定哪些依賴適合打包。
當找不到或無法安裝依賴項時，npm install 命令會退出并顯示錯誤。如果特定軟件包存在于 optionalDependencies 而不是其他任何依賴項列表/字典中，則可以阻止出現此情況。
在 package.json 中,optionalDependencies 字段用于指定哪些依賴可以被視為可選的。
例如:
{ "optionalDependencies": { "xx": "^1.0.0" }}這表示 xx 這個依賴是可選的,如果安裝過程中無法滿足,npm 會繼續正常安裝,只是發出警告。
optionalDependencies 和 dependencies 的區別在于:
optionalDependencies 的常見使用場景:
使用 optionalDependencies 表示可選依賴,可以很好地提升使用者的安裝體驗,避免因為某些非核心依賴而導致整個安裝失敗。
還記得我們在發布f_cli時候，通過optionalDependencies來指定相關工作環境的二進制包嗎。
圖片
我們可以使用此選項指定軟件包是否應該是公開可訪問的，以及軟件包使用哪個標簽發布。默認情況下，軟件包是私有的，并且默認標簽是 latest。使用不同的標簽，例如 beta，允許用戶使用npm install <package-name>@beta安裝軟件包的特定版本。
在 package.json 中,publishConfig 用于配置發布這個包時的一些設置。
其中常見的配置有:
例如:
{ "publishConfig": { "registry": "https://私有注冊表網址", "tag": "internal" }}這意味著發布這個包時會發布到私有注冊表,并打上 internal 的 tag。
publishConfig 的常見使用場景:
所以 publishConfig 可以很好地自定義包的發布過程,將其發布到特定的注冊表或添加自定義標簽。
另外,發布過程還可以通過 npm publish 命令的 --tag 參數動態配置。
workspaces字段用于定義 monorepo 結構中的多個 package。
例如:
{ "name": "monorepo", "workspaces": [ "packages/*" ]}這表示packages目錄下的「所有子目錄都會被當作獨立的 package,可以相互依賴和發布」。
啟用 workspaces 后,在根目錄運行類似npm install、npm run build等命令,會自動在所有 workspace 包中生效。
workspaces的常見使用場景:
與普通的多包管理相比,workspaces 可以減少重復工作,大幅簡化 monorepo 開發。
需要注意的是,所有 workspace 需要遵循相同的npm包規則,如版本控制、發布模式等,以減少管理負擔。
這個選項在單體倉庫中非常有用。我們可以以以下方式指定工作空間的列表：
{ "workspaces": [ "./packages/client", "./packages/server" ]}我們可以在 client 和 server 目錄中有單獨的 package.json 文件，其中包含單獨的腳本。運行 npm install --workspaces 將在兩個目錄中運行 npm install。
實際上，我們可以使用--workspaces 命令在指定的所有工作空間中運行任何腳本。
例如，如果在 packages/client 和 packages/server 中有單獨的 lint 腳本，在根 package.json 中，我們可以有一個 lint 腳本。現在，如果在根目錄中運行 npm run lint --workspaces --if-present，它將在所有具有 lint 腳本的工作空間中運行 lint 腳本。
--if-present 保證即使有些包沒有 lint 腳本,也不會影響其它包的執行。
在我們的 npm 項目中安裝軟件包時，通常會出現一個神秘的 package-lock.json 文件。
正如名稱所示，package-lock.json 是一個鎖定文件，即一個「存儲了使用的軟件包及其所有依賴軟件包的確切版本號的文件」。這包括在我們的 node_modules 目錄中存在的所有軟件包。
該文件的目的是確保所有依賴項在不同的機器上以相同的方式安裝，從而保證項目在不同環境中能夠一致工作。
package-lock.json 文件還包括每個軟件包內容的加密哈希，這確保安裝的軟件包未被篡改，并且與軟件包作者發布的確切相同的軟件包。
當我們運行 npm install 時，npm 使用 package-lock.json 中的信息確定要安裝的軟件包的確切版本，并以與原始安裝相同的順序和相同的依賴項安裝它們。
盡管 npm 是最流行的包管理器之一，但很多人也使用其他包管理器，如 yarn、pnpm 或 turbo。這些包管理器中仍然存在 package.json 文件，但不同的包管理器可能使用不同的名稱來命名鎖文件。例如，yarn 創建的 鎖文件 稱為 yarn.lock，看起來類似于以下內容：
# THIS IS AN AUTOGENERATED FILE. DO NOT EDIT THIS FILE DIRECTLY.# yarn lockfile v1package-1@^1.0.0: version "1.0.3" resolved "https://registry.npmjs.org/package-1/-/package-1-1.0.3.tgz#a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0"package-2@^2.0.0: version "2.0.1" resolved "https://registry.npmjs.org/package-2/-/package-2-2.0.1.tgz#a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0" dependencies: package-4 "^4.0.0"package-3@^3.0.0: version "3.1.9" resolved "https://registry.npmjs.org/package-3/-/package-3-3.1.9.tgz#a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0" dependencies: package-4 "^4.5.0"package-4@^4.0.0, package-4@^4.5.0: version "4.6.3" resolved "https://registry.npmjs.org/package-4/-/package-4-2.6.3.tgz#a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0"類似地，pnpm 生成一個稱為 pnpm-lock.yaml 的 鎖文件。然而，所有這些 lockfile 的目的與 npm 生成的 package-lock.json 文件相同。
總的來說，package.json是 Node.js 開發中使用的重要元數據文件。它有助于管理依賴關系、自動化任務并配置項目。該文件包含了項目名稱、版本號、作者、許可證、依賴關系等基本信息。
通過使用 package.json，我們可以輕松管理項目所需的依賴項，確保安裝每個軟件包的正確版本。這使得更容易維護項目并在必要時更新依賴項。
此外，它還可以用于自動化任務，如構建項目、運行測試和啟動應用程序。這可以為我們節省時間和精力，使他們能夠專注于項目的更重要方面。
最后，它允許我們將其項目發布到 npmjs，使其他用戶能夠輕松安裝和在自己的項目中使用該項目。
本文鏈接：http://www.www897cc.com/showinfo-26-71450-0.html你真的了解package.json嗎？
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 徹底理解內存泄漏，你學會了嗎？
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號