npm package.json属性详解

时间 2019-11-11

标签 npm package.json package json 属性详解栏目 JavaScript 繁體版

原文原文链接

概述

本文档是本身看官方文档的理解+翻译，内容是package.json配置里边的属性含义。package.json必须是一个严格的json文件，而不只仅是js里边的一个对象。其中不少属性能够经过npm-config来生成。node

name

package.json中最重要的属性是name和version两个属性，这两个属性是必需要有的，不然模块就没法被安装，这两个属性一块儿造成了一个npm模块的惟一标识符。模块中内容变动的同时，模块版本也应该一块儿变化。
name属性就是你的模块名称，下面是一些命名规则:linux

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)的文档中能够看到详细说明git

version

version必须能够被npm依赖的一个node-semver模块解析。具体规则见下面的dependencies模块github

description

一个描述，方便别人了解你的模块做用，搜索的时候也有用。express

keywords

一个字符串数组，方便别人搜索到本模块npm

homepage

项目主页url
注意: 这个项目主页url和url属性不一样，若是你填写了url属性，npm注册工具会认为你把项目发布到其余地方了，获取模块的时候不会从npm官方仓库获取，而是会重定向到url属性配置的地址。
（原文档中用了 spit(吐)这个单词，做者表示他不是在开玩笑:）json

bugs

填写一个bug提交地址或者一个邮箱，被你的模块坑到的人能够经过这里吐槽，例如：windows

{ "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