npm package.json屬性詳解

概述

本文檔是本身看官方文檔的理解+翻譯，內容是package.json配置裏邊的屬性含義。package.json必須是一個嚴格的json文件，而不只僅是js裏邊的一個對象。其中不少屬性能夠經過npm-config來生成。

name

package.json中最重要的屬性是name和version兩個屬性，這兩個屬性是必需要有的，不然模塊就沒法被安裝，這兩個屬性一塊兒造成了一個npm模塊的惟一標識符。模塊中內容變動的同時，模塊版本也應該一塊兒變化。
name屬性就是你的模塊名稱，下面是一些命名規則:

• name必須小於等於214個字節，包括前綴名稱在內（如 xxx/xxxmodule）。
  
• name不能以"_"或"."開頭
  
• 不能含有大寫字母
  
• name會成爲url的一部分，不能含有url非法字符
  下面是官網文檔的一些建議：
• 不要使用和node核心模塊同樣的名稱
  
• name中不要含有"js"和"node"。 It's assumed that it's js, since you're writing a package.json file, and you can specify the engine using the "engines" field. (See below.)
• name屬性會成爲模塊url、命令行中的一個參數或者一個文件夾名稱，任何非url安全的字符在name中都不能使用，也不能以"_"或"."開頭
• name屬性也許會被寫在require()的參數中，因此最好取個簡短而語義化的值。
• 建立一個模塊前能夠先到後邊的網址查查name是否已經被佔用. https://www.npmjs.com/

name屬性能夠有一些前綴如 e.g. @myorg/mypackage.在npm-scope(7)的文檔中能夠看到詳細說明

version

version必須能夠被npm依賴的一個node-semver模塊解析。具體規則見下面的dependencies模塊

description

一個描述，方便別人瞭解你的模塊做用，搜索的時候也有用。

keywords

一個字符串數組，方便別人搜索到本模塊

homepage

項目主頁url
注意: 這個項目主頁url和url屬性不一樣，若是你填寫了url屬性，npm註冊工具會認爲你把項目發佈到其餘地方了，獲取模塊的時候不會從npm官方倉庫獲取，而是會重定向到url屬性配置的地址。
（原文檔中用了 spit(吐)這個單詞，做者表示他不是在開玩笑:）

bugs

填寫一個bug提交地址或者一個郵箱，被你的模塊坑到的人能夠經過這裏吐槽，例如：

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

url和email能夠任意填或不填，若是隻填一個，能夠直接寫成一個字符串而不是對象。若是填寫了url，npm bugs命令會使用這個url。

license

你應該爲你的模塊制定一個協議，讓用戶知道他們有何權限來使用你的模塊，以及使用該模塊有哪些限制。最簡單的，例如你用BSD-3-Clause 或 MIT之類的協議，以下：
{ "license" : "BSD-3-Clause" }
你能夠在https://spdx.org/licenses/這個地址查閱協議列表 。

和用戶相關的屬性: author, contributors

"author"是一個碼農， "contributors"是一個碼農數組。 "person"是一個有一些描述屬性的對象，以下 like this:

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

也能夠按以下格式縮寫，npm會幫着轉換:
"Barney Rubble b@rubble.com (http://barnyrubble.tumblr.com/)"
email和url屬性實際上都是能夠省略的。描述用戶信息的還有一個"maintainers"（維護者）屬性。

files

"files"屬性的值是一個數組，內容是模塊下文件名或者文件夾名，若是是文件夾名，則文件夾下全部的文件也會被包含進來（除非文件被另外一些配置排除了）
你也能夠在模塊根目錄下建立一個".npmignore"文件（windows下沒法直接建立以"."開頭的文件，使用linux命令行工具建立如git bash），寫在這個文件裏邊的文件即使被寫在files屬性裏邊也會被排除在外，這個文件的寫法".gitignore"相似。

main

main屬性指定了程序的主入口文件。意思是，若是你的模塊被命名爲foo，用戶安裝了這個模塊並經過require("foo")來使用這個模塊，那麼require返回的內容就是main屬性指定的文件中 module.exports指向的對象。
它應該指向模塊根目錄下的一個文件。對大對數模塊而言，這個屬性更多的是讓模塊有一個主入口文件，然而不少模塊並不寫這個屬性。

bin

不少模塊有一個或多個須要配置到PATH路徑下的可執行模塊，npm讓這個工做變得十分簡單（實際上npm自己也是經過bin屬性安裝爲一個可執行命令的）
若是要用npm的這個功能，在package.json裏邊配置一個bin屬性。bin屬性是一個已命令名稱爲key，本地文件名稱爲value的map以下：

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

模塊安裝的時候，如果全局安裝，則npm會爲bin中配置的文件在bin目錄下建立一個軟鏈接（對於windows系統，默認會在C:\Users\username\AppData\Roaming\npm目錄下），如果局部安裝，則會在項目內的./node_modules/.bin/目錄下建立一個軟連接。
所以，按上面的例子，當你安裝myapp的時候，npm就會爲cli.js在/usr/local/bin/myapp路徑建立一個軟連接。
若是你的模塊只有一個可執行文件，而且它的命令名稱和模塊名稱同樣，你能夠只寫一個字符串來代替上面那種配置，例如：

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

做用和以下寫法相同:

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

man

制定一個或經過數組制定一些文件來讓linux下的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 文件的內容。
若是man文件名稱不是以模塊名稱開頭的，安裝的時候會給加上模塊名稱前綴。所以，下面這段配置：

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

會建立一些文件來做爲man foo和man foo-bar命令的結果。
man文件必須以數字結尾，或者若是被壓縮了，以.gz結尾。數字表示文件將被安裝到man的哪一個部分。

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

會建立 man foo 和 man 2 foo 兩條命令。

directories

CommonJs經過directories來制定一些方法來描述模塊的結構，看看npm的package.json文件https://registry.npmjs.org/npm/latest ，能夠發現裏邊有這個字段的內容。

目前這個配置沒有任何做用，未來可能會整出一些花樣來。

directories.lib

告訴用戶模塊中lib目錄在哪，這個配置目前沒有任何做用，可是對使用模塊的人來講是一個頗有用的信息。

directories.bin

若是你在這裏指定了bin目錄，這個配置下面的文件會被加入到bin路徑下，若是你已經在package.json中配置了bin目錄，那麼這裏的配置將不起任何做用。

directories.man

指定一個目錄，目錄裏邊都是man文件，這是一種配置man文件的語法糖。

directories.doc

在這個目錄裏邊放一些markdown文件，可能最終有一天它們會被友好的展示出來（應該是在npm的網站上）

directories.example

放一些示例腳本，或許某一天會有用 - -！

repository

指定一個代碼存放地址，對想要爲你的項目貢獻代碼的人有幫助。像這樣：

"repository" :
  { "type" : "git"
  , "url" : "https://github.com/npm/npm.git"
  }

"repository" :
  { "type" : "svn"
  , "url" : "https://v8.googlecode.com/svn/trunk/"
  }

若你的模塊放在GitHub, GitHub gist, Bitbucket, or GitLab的倉庫裏，npm install的時候可使用縮寫標記來完成：

"repository": "npm/npm"

"repository": "gist:11081aaa281"

"repository": "bitbucket:example/repo"

"repository": "gitlab:another/repo"

scripts

scripts屬性是一個對象，裏邊指定了項目的生命週期個各個環節須要執行的命令。key是生命週期中的事件，value是要執行的命令。
具體的內容有 install start stop 等，詳見https://docs.npmjs.com/misc/scripts

config

用來設置一些項目不怎麼變化的項目配置，例如port等。
用戶用的時候可使用以下用法：

http.createServer(...).listen(process.env.npm_package_config_port)

能夠經過npm config set foo:port 80來修改config。詳見https://docs.npmjs.com/misc/config

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

dependencies

dependencies屬性是一個對象，配置模塊依賴的模塊列表，key是模塊名稱，value是版本範圍，版本範圍是一個字符，能夠被一個或多個空格分割。
dependencies也能夠被指定爲一個git地址或者一個壓縮包地址。
不要把測試工具或transpilers寫到dependencies中。 下面是一些寫法，詳見https://docs.npmjs.com/misc/semver

• version 精確匹配版本
  
• >version 必須大於某個版本
  
• >=version 大於等於
  
• <version 小於
  
• <=versionversion 小於
  
• ~version "約等於"，具體規則詳見semver文檔
  
• ^version "兼容版本"具體規則詳見semver文檔
  
• 1.2.x 僅一點二點幾的版本
  
• http://... 見下面url做爲denpendencies的說明
  
• • 任何版本
    
• "" 空字符，和*相同
  
• version1 - version2 至關於 >=version1 <=version2.
  
• range1 || range2 範圍1和範圍2知足任意一個都行
  
• git... 見下面git url做爲denpendencies的說明
  
• user/repo See 見下面GitHub倉庫的說明
  
• tag 發佈的一個特殊的標籤，見npm-tag的文檔 https://docs.npmjs.com/getting-started/using-tags
  
• path/path/path 見下面本地模塊的說明
  下面的寫法都是能夠的:

{ "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"
  , "dyl" : "file:../dyl"
  }
}

URLs as Dependencies

在版本範圍的地方能夠寫一個url指向一個壓縮包，模塊安裝的時候會把這個壓縮包下載下來安裝到模塊本地。

Git URLs as Dependencies

Git url能夠像下面同樣:

git://github.com/user/project.git#commit-ish
git+ssh://user@hostname:project.git#commit-ish
git+ssh://user@hostname/project.git#commit-ish
git+http://user@hostname/project/blah.git#commit-ish
git+https://user@hostname/project/blah.git#commit-ish

commit-ish 能夠是任意標籤，哈希值，或者能夠檢出的分支，默認是master分支。

GitHub URLs

支持github的 username/modulename 的寫法，#後邊能夠加後綴寫明分支hash或標籤：

{
  "name": "foo",
  "version": "0.0.0",
  "dependencies": {
    "express": "visionmedia/express",
    "mocha": "visionmedia/mocha#4727d357ea"
  }
}

Local Paths

npm2.0.0版本以上能夠提供一個本地路徑來安裝一個本地的模塊，經過npm install xxx --save 來安裝，格式以下：

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

package.json 生成的相對路徑以下:

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

這種屬性在離線開發或者測試須要用npm install的狀況，又不想本身搞一個npm server的時候有用，可是發佈模塊到公共倉庫時不該該使用這種屬性。

devDependencies

若是有人想要下載並使用你的模塊，也許他們並不但願或須要下載一些你在開發過程當中使用的額外的測試或者文檔框架。
在這種狀況下，最好的方法是把這些依賴添加到devDependencies屬性的對象中。
這些模塊會在npm link或者npm install的時候被安裝，也能夠像其餘npm配置同樣被管理，詳見npm的config文檔。
對於一些跨平臺的構建任務，例如把CoffeeScript編譯成JavaScript，就能夠經過在package.json的script屬性裏邊配置prepublish腳原本完成這個任務，而後須要依賴的coffee-script模塊就寫在devDependencies屬性種。
例如:

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

prepublish腳本會在發佈以前運行，所以用戶在使用以前就不用再本身去完成編譯的過程了。在開發模式下，運行npm install也會執行這個腳本（見npm script文檔），所以能夠很方便的調試。

peerDependencies

有時候作一些插件開發，好比grunt等工具的插件，它們每每是在grunt的某個版本的基礎上開發的，而在他們的代碼中並不會出現require("grunt")這樣的依賴，dependencies配置裏邊也不會寫上grunt的依賴，爲了說明此模塊只能做爲插件跑在宿主的某個版本範圍下，能夠配置peerDependencies：

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

上面這個配置確保再npm install的時候tea-latte會和2.x版本的tea一塊兒安裝，並且它們兩個的依賴關係是同級的：
├── tea-latte@1.3.5
└── tea@2.2.0
這個配置的目的是讓npm知道，若是要使用此插件模塊，請確保安裝了兼容版本的宿主模塊。

bundledDependencies

上面的單詞少個d，寫成bundleDependencies也能夠。
指定發佈的時候會被一塊兒打包的模塊。

optionalDependencies

若是一個依賴模塊能夠被使用， 同時你也但願在該模塊找不到或沒法獲取時npm繼續運行，你能夠把這個模塊依賴放到optionalDependencies配置中。這個配置的寫法和dependencies的寫法同樣，不一樣的是這裏邊寫的模塊安裝失敗不會致使npm install失敗。
固然，這種模塊就須要你本身在代碼中處理模塊確實的狀況了，例如：

try {
  var foo = require('foo')
  var fooVersion = require('foo/package.json').version
} catch (er) {
  foo = null
}
if ( notGoodFooVersion(fooVersion) ) {
  foo = null
}

// .. then later in your program ..

if (foo) {
  foo.doFooThings()
}

optionalDependencies 中的配置會覆蓋dependencies中的配置，最好只在一個地方寫。

engines

你能夠指定項目運行的node版本範圍，以下：
{ "engines" : { "node" : ">=0.10.3 <0.12" } }
和dependencies同樣，若是你不指定版本範圍或者指定爲*，任何版本的node均可以。
也能夠指定一些npm版本能夠正確的安裝你的模塊，例如：
{ "engines" : { "npm" : "~1.0.20" } }
要注意的是，除非你設置了engine-strict屬性，engines屬性是僅供參考的。

engineStrict

注意：這個屬性已經棄用，將在npm 3.0.0 版本幹掉。

os

能夠指定你的模塊只能在哪一個操做系統上跑：
"os" : [ "darwin", "linux" ]
也能夠指定黑名單而不是白名單：
"os" : [ "!win32" ]
服務的操做系統是由process.platform來判斷的，這個屬性容許黑白名單同時存在，雖然沒啥必要這樣搞...

cpu

限制模塊只能在某某cpu架構下運行
"cpu" : [ "x64", "ia32" ]
一樣能夠設置黑名單:
"cpu" : [ "!arm", "!mips" ]
cpu架構經過 process.arch 判斷

preferGlobal

若是您的軟件包主要用於安裝到全局的命令行應用程序，那麼該值設置爲true ，若是它被安裝在本地，則提供一個警告。實際上該配置並無阻止用戶把模塊安裝到本地，只是防止該模塊被錯誤的使用引發一些問題。

private

若是這個屬性被設置爲true，npm將拒絕發佈它，這是爲了防止一個私有模塊被無心間發佈出去。若是你只想讓模塊被髮布到一個特定的npm倉庫，如一個內部的倉庫，可與在下面的publishConfig中配置倉庫參數。

publishConfig

這個配置是會在模塊發佈時用到的一些值的集合。若是你不想模塊被默認被標記爲最新的，或者默認發佈到公共倉庫，能夠在這裏配置tag或倉庫地址。

DEFAULT VALUES

npm設置了一些默認參數，如：
"scripts": {"start": "node server.js"}
若是模塊根目錄下有一個server.js文件，那麼npm start會默認運行這個文件。
"scripts":{"preinstall": "node-gyp rebuild"}
若是模塊根目錄下有binding.gyp, npm將默認用node-gyp來編譯preinstall的腳本
"contributors": [...]
若模塊根目錄下有AUTHORS 文件，則npm會按Name (url)格式解析每一行的數據添加到contributors中，能夠用#添加行註釋

參考文檔列表(https://docs.npmjs.com/)

semver(7)
npm-init(1)
npm-version(1)
npm-config(1)
npm-config(7)
npm-help(1)
npm-faq(7)
npm-install(1)
npm-publish(1)
npm-rm(1)

轉自個人我的博客，原文地址：http://zoucz.com/blog/2016/02/17/npm-package