溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要介紹“package.json的屬性有哪些”的相關知識，小編通過實際案例向大家展示操作過程，操作方法簡單快捷，實用性強，希望這篇“package.json的屬性有哪些”文章能幫助大家解決問題。
package.json必須是一個嚴格的json文件，而不僅僅是js里邊的一個對象。其中很多屬性可以通過npm-config來生成
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是否已經被占用. www.npmjs.com/
# 發布一個包的時候，需要檢驗某個包名是否存在 npm search <ModuleName>
name屬性可以有一些前綴如 e.g. @myorg/mypackage.在npm-scope(7)的文檔中可以看到詳細說明
version必須可以被npm依賴的一個node-semver模塊解析。具體規則見下面的dependencies模塊
一個描述，方便別人了解你的模塊作用，搜索的時候也有用。
一個字符串數組，方便別人搜索到本模塊
項目主頁url 注意: 這個項目主頁url和url屬性不同，如果你填寫了url屬性，npm注冊工具會認為你把項目發布到其他地方了，獲取模塊的時候不會從npm官方倉庫獲取，而是會重定向到url屬性配置的地址。 （原文檔中用了 spit(吐)這個單詞，作者表示他不是在開玩笑:）
填寫一個bug提交地址或者一個郵箱，被你的模塊坑到的人可以通過這里吐槽，例如：
{
"url" : "https://github.com/owner/project/issues",
"email" : "project@hostname.com"
}url和email可以任意填或不填，如果只填一個，可以直接寫成一個字符串而不是對象。如果填寫了url，npm bugs命令會使用這個url。
你應該為你的模塊制定一個協議，讓用戶知道他們有何權限來使用你的模塊，以及使用該模塊有哪些限制。最簡單的，例如你用BSD-3-Clause 或 MIT之類的協議，如下：
{ "license" : "MIT" }你可以在spdx.org/licenses/ 這個地址查閱協議列表 。
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屬性的值是一個數組，內容是模塊下文件名或者文件夾名，如果是文件夾名，則文件夾下所有的文件也會被包含進來（除非文件被另一些配置排除了） 你也可以在模塊根目錄下創建一個.npmignore文件（windows下無法直接創建以"."開頭的文件，使用linux命令行工具創建如git bash），寫在這個文件里邊的文件即便被寫在files屬性里邊也會被排除在外，這個文件的寫法".gitignore"類似。
main屬性指定了程序的主入口文件。意思是，如果你的模塊被命名為foo，用戶安裝了這個模塊并通過require("foo")來使用這個模塊，那么require返回的內容就是main屬性指定的文件中 module.exports指向的對象。 它應該指向模塊根目錄下的一個文件。對大對數模塊而言，這個屬性更多的是讓模塊有一個主入口文件，然而很多模塊并不寫這個屬性。
很多模塊有一個或多個需要配置到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"
}
}制定一個或通過數組制定一些文件來讓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 兩條命令。
CommonJs通過directories來制定一些方法來描述模塊的結構，看看npm的package.json文件registry.npmjs.org/npm/latest 。
告訴用戶模塊中lib目錄在哪，這個配置目前沒有任何作用，但是對使用模塊的人來說是一個很有用的信息。
如果你在這里指定了bin目錄，這個配置下面的文件會被加入到bin路徑下，如果你已經在package.json中配置了bin目錄，那么這里的配置將不起任何作用。
指定一個目錄，目錄里邊都是man文件，這是一種配置man文件的語法糖。
在這個目錄里邊放一些markdown文件，可能最終有一天它們會被友好的展現出來（應該是在npm的網站上）
放一些示例腳本，或許某一天會有用 - -！
指定一個代碼存放地址，對想要為你的項目貢獻代碼的人有幫助。像這樣：
"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屬性是一個對象，里邊指定了項目的生命周期個各個環節需要執行的命令。key是生命周期中的事件，value是要執行的命令。 具體的內容有 install start stop 等，詳見 https://docs.npmjs.com/misc/scripts
用來設置一些項目不怎么變化的項目配置，例如port等。 用戶用的時候可以使用如下用法：
http.createServer(...).listen(process.env.npm_package_config_port)
可以通過npm config set foo:port 80來修改config。詳見docs.npmjs.com/misc/config
{
"name" : "foo",
"config" : { "port" : "8080" }
}dependencies屬性是一個對象，配置模塊依賴的模塊列表，key是模塊名稱，value是版本范圍，版本范圍是一個字符，可以被一個或多個空格分割。 dependencies也可以被指定為一個git地址或者一個壓縮包地址。 不要把測試工具或transpilers寫到dependencies中。 下面是一些寫法，詳見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的文檔 docs.npmjs.com/getting-sta…
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"
}
}在版本范圍的地方可以寫一個url指向一個壓縮包，模塊安裝的時候會把這個壓縮包下載下來安裝到模塊本地。
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的 username/modulename 的寫法，#后邊可以加后綴寫明分支hash或標簽：
{
"name": "foo",
"version": "0.0.0",
"dependencies": {
"express": "visionmedia/express",
"mocha": "visionmedia/mocha#4727d357ea"
}
}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屬性的對象中。 這些模塊會在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文檔），因此可以很方便的調試。
有時候做一些插件開發，比如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知道，如果要使用此插件模塊，請確保安裝了兼容版本的宿主模塊。
上面的單詞少個d，寫成bundleDependencies也可以。 指定發布的時候會被一起打包的模塊。
如果一個依賴模塊可以被使用， 同時你也希望在該模塊找不到或無法獲取時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中的配置，最好只在一個地方寫。
你可以指定項目運行的node版本范圍，如下： { "engines" : { "node" : ">=0.10.3 <0.12" } } 和dependencies一樣，如果你不指定版本范圍或者指定為*，任何版本的node都可以。 也可以指定一些npm版本可以正確的安裝你的模塊，例如： { "engines" : { "npm" : "~1.0.20" } } 要注意的是，除非你設置了engine-strict屬性，engines屬性是僅供參考的。
注意：這個屬性已經棄用，將在npm 3.0.0 版本干掉。
可以指定你的模塊只能在哪個操作系統上跑： "os" : [ "darwin", "linux" ] 也可以指定黑名單而不是白名單： "os" : [ "!win32" ] 服務的操作系統是由process.platform來判斷的，這個屬性允許黑白名單同時存在，雖然沒啥必要這樣搞...
限制模塊只能在某某cpu架構下運行 "cpu" : [ "x64", "ia32" ] 同樣可以設置黑名單: "cpu" : [ "!arm", "!mips" ] cpu架構通過 process.arch 判斷
如果您的軟件包主要用于安裝到全局的命令行應用程序，那么該值設置為true ，如果它被安裝在本地，則提供一個警告。實際上該配置并沒有阻止用戶把模塊安裝到本地，只是防止該模塊被錯誤的使用引起一些問題。
如果這個屬性被設置為true，npm將拒絕發布它，這是為了防止一個私有模塊被無意間發布出去。如果你只想讓模塊被發布到一個特定的npm倉庫，如一個內部的倉庫，可與在下面的publishConfig中配置倉庫參數。
這個配置是會在模塊發布時用到的一些值的集合。如果你不想模塊被默認被標記為最新的，或者默認發布到公共倉庫，可以在這里配置tag或倉庫地址。
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中，可以用#添加行注釋.
關于“package.json的屬性有哪些”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識，可以關注億速云行業資訊頻道，小編每天都會為大家更新不同的知識點。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
