什麼是Node.js的模組（Module）？
在Node.js中，模組是一個庫或框架，也是一個Node.js專案。Node.js專案遵循模組化的架構，當我們建立了一個Node.js專案，意味著建立了一個模組，這個模組的描述檔案，被稱為package.json —— 【長城_changcheng】

一般package.json放置在專案根目錄下，其基本結構如下圖所示：

package.json 結構圖

屬性介紹

description

字串。用來描述當前專案的大致功能。

name

此專案包的名稱。在不確定自己的包名能否使用之前，請先npm registry 一下，看看當前你喜歡的包名是否已經被佔用。

version

當前專案包的版本號。每一次專案改動時，在即將釋出時，都要同步的去更改專案的版本號。一般格式為：x.y.z。意思是：大版本.中版本.小版本

keywords

放簡介，字串。方便屌絲們在 npm search中搜索

homepage

專案官網的url

bugs

你專案的提交問題的url和（或）郵件地址。這對遇到問題的屌絲很有幫助。

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

你可以指定一個或者指定兩個。如果你只想提供一個url，那就不用物件了，字串就行。如果提供了url，它會被npm bugs命令使用。

license

你應該要指定一個許可證，讓人知道使用的權利和限制的。最簡單的方法是，假如你用一個像BSD或者MIT這樣通用的許可證，就只需要指定一個許可證的名字，像這樣：

{ "license" : "BSD" }

author

專案作者。可以指定name，email，url欄位資訊。也可以單獨使用字串來表示。

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

contributors

專案相關貢獻者。是陣列。用於羅列對應的貢獻人。可以是單獨的字串，也可以分別指定name,email,url等屬性。

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

files

files是一個包含專案中的檔案的陣列。如果命名了一個資料夾，那也會包含資料夾中的檔案。（除非被其他條件忽略了）你也可以提供一個.npmignore檔案，讓即使被包含在files欄位中得檔案被留下。其實就像.gitignore一樣。

{ "files": [ "bin/","templates/","test/" ]}

main

main欄位是一個模組ID，它是一個指向你程式的主要專案。就是說，如果你包的名字叫foo，然後使用者安裝它，然後require("foo")，然後你的main模組的exports物件會被返回。這應該是一個相對於根目錄的模組ID。對於大多數模組，它是非常有意義的，其他的都沒啥。

{ "main": "bin/index.js"}

bin

很多包都有一個或多個可執行的檔案希望被放到PATH中。（實際上，就是這個功能讓npm可執行的）。要用這個功能，給package.json中的bin欄位一個命令名到檔案位置的map。初始化的時候npm會將他連結到prefix/bin（全域性初始化）或者./node_modules/.bin/（本地初始化）。

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

當你初始化npm，它會建立一個符號連結到cli.js指令碼到/usr/local/bin/npm。如果你只有一個可執行檔案，並且名字和包名一樣。那麼你可以只用一個字串，比如

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

// 等價於

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

man

指定一個單一的檔案或者一個檔案陣列供man程式使用。如果只提供一個單一的檔案，那麼它初始化後就是man 的結果，而不管實際的檔名是神馬，比如：

{ "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檔案了。

如果檔名不是以包名開頭，那麼它會被冠以字首，下面的：

{ "name" : "foo","man" : [ "./man/foo.1","./man/bar.1" ] }

會為man foo和man foo-bar建立檔案。

man檔案需要以數字結束，然後可選地壓縮後以.gz為字尾。

{ "name" : "foo","./man/foo.2" ] }

會為man foo和man 2 foo建立。

repository

指定你的程式碼存放的地方。這個對希望貢獻的人有幫助。如果git倉庫在github上，那麼npm docs命令能找到你。

scripts

“scripts”是一個由指令碼命令組成的hash物件，他們在包不同的生命週期中被執行。key是生命週期事件，value是要執行的命令。

config

"config" hash可以用來配置用於包指令碼中的跨版本引數。在例項中，如果一個包有下面的配置

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

然後有一個“start”命令引用了npm_package_config_port環境變數，使用者可以通過npm config set foo:port 8001來重寫他。

dependencies

依賴是給一組包名指定版本範圍的一個hash。這個版本範圍是一個由一個或多個空格分隔的字串。依賴還可以用tarball或者git URL。

請不要將測試或過渡性的依賴放在dependencies。

對於引用包的版本號格式，以下都是合法的：

{ "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","vue":"*","element-ui":"" } }

devDependencies

如果有人要用你的模組，但他們可能不需要你開發所使用的外部測試或者文件框架。在這種情況下，最好將這些附屬的專案列在devDependencies中。這些東西會在根目錄執行npm link或者npm install的時候初始化，並可以像其他npm配置引數一樣管理。

peerDependencies

你的模組可能要暴露一個特定的介面，並由host文件來預期和指定。比如：

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

這能保證你的package可以只和tea的2.x版本一起初始化。試圖初始化另一個有會衝突的依賴的外掛將導致一個錯誤。因此，確保你的外掛的需求約束越弱越好，而不要去把它鎖定到一個特定的版本。此屬性儘量避免使用

bundledDependencies

一組包名，他們會在釋出的時候被打包進去

engines

指定專案工作的環境。除非使用者設定engine-strict標記，這個欄位只是建議值。

{ "engines" : { "node" : ">=0.10.3 <0.12","npm" : "~1.0.20" } }

engineStrict

如果你確定你的模組一定不會執行在你指定版本之外的node或者npm上，你可以在package.json檔案中設定"engineStrict":true。它會重寫使用者的engine-strict設定。除非你非常非常確定，否則不要這樣做。如果你的engines hash過度地限制，很可能輕易讓自己陷入窘境。慎重地考慮這個選擇。如果大家濫用它，它會再以後的npm版本中被刪除。

os

可以指定你的模組要執行在哪些作業系統中

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

你也可以用黑名單代替白名單，在名字前面加上“!”就可以了：

"os" : [ "!win32" ]

作業系統用process.platform來探測。雖然沒有很好地理由，但它是同時支援黑名單和白名單的。

cpu

如果你的程式碼只能執行在特定的cpu架構下，你可以指定一個

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

就像os選項，你也可以黑一個架構：

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

cpu架構用process.arch探測。

preferGlobal

如果包主要是需要全域性安裝的命令列程式，就設定它為true來提供一個warning給只在區域性安裝的人。它不會真正的防止使用者在區域性安裝，但如果它沒有按預期工作它會幫助防止產生誤會。

{" preferGlobal ":true}

private

如果你設定"private": true，npm就不會發布它。

這是一個防止意外發布私有庫的方式。如果你要確定給定的包是隻釋出在特定registry（如內部registry）的，用publishConfighash的描述來重寫registry的publish-time配置引數。

publishConfig

這是一個在publish-time使用的配置集合。當你想設定tag或者registry的時候它非常有用，所以你可以確定一個給定的包沒有打上“lastest”的tag或者被預設釋出到全域性的公開registry。任何配置都可以被重寫，但當然可能只有“tag”和“registry”與釋出的意圖有關。

到此這篇關於package.json各個屬性說明詳解的文章就介紹到這了,更多相關package.json屬性內容請搜尋我們以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援我們！