name

在大多数在你的package.json重要的事件是名称和版本字段。这些实际上是必须的，没有它们，您的软件包将无奈装置。名称和版本一起形成一个标识符，该标识符被认为是齐全惟一的。对软件包的更改应与版本的更改同时进行。

名字就是你的名字。

一些规定：

  • 名称必须少于或等于214个字符。这包含范畴包的范畴。
  • 名称不能以点或下划线结尾。
  • 新软件包名称中不得蕴含大写字母。
  • 该名称最终成为URL，命令行参数和文件夹名称的一部分。因而，该名称不能蕴含任何非URL平安的字符。

一些技巧：

  • 不要应用与外围Node模块雷同的名称。
  • 不要在名称中增加“ js”或“ node”。假如它是js，因为您正在编写package.json文件，并且能够应用“ engines”字段指定引擎。（见下文。）
  • 该名称可能会作为参数传递给require（），因而它应该简短一些，但也应具备正当的描述性。
  • 您可能须要查看npm注册表，以查看是否曾经有该名称的货色，而后再附加它。https://www.npmjs.com/

名称能够可选地以范畴为前缀，例如@myorg/mypackage。请参阅 npm-scope以获取更多详细信息。

version

在大多数在你的package.json重要的事件是名称和版本字段。这些实际上是必须的，没有它们，您的软件包将无奈装置。名称和版本一起形成一个标识符，该标识符被认为是齐全惟一的。对软件包的更改应与版本的更改同时进行。

版本必须能够由node-semver解析 ，它与npm捆绑在一起作为依赖项。（npm install semver本人应用）。

无关版本号和范畴的更多信息，请参见semver。

description

在其中增加形容。这是一个字符串。如中所列，这能够帮忙人们发现您的包

keywords

在其中放入关键字。它是一个字符串数组。这能够帮忙人们发现您的软件包

homepage

我的项目首页的网址

bugs

我的项目的问题跟踪器的URL和/或应向其报告问题的电子邮件地址。这些对于遇到您的包问题的人很有帮忙。

它看起来应该像这样：

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

您能够指定一个或两个值。如果您只想提供一个url，则能够将“ bugs”的值指定为简略字符串而不是对象。

如果提供了URL，则该npm bugs命令将应用它。

license

您应该为包指定许可证，以便人们晓得如何应用它们以及您对该包裹施加的任何限度。

如果您应用的是通用许可证，例如BSD-2-Clause或MIT，请为所应用的许可证增加以后SPDX许可证标识符，如下所示：

{ "license" : "BSD-3-Clause" }

您能够查看SPDX许可证ID的残缺列表。现实状况下，您应该抉择通过 OSI批准的产品。

如果您的软件包已取得多个通用许可证的许可，请应用SPDX许可证表达式语法版本2.0字符串，如下所示：

{ "license" : "(ISC OR GPL-3.0)" }

如果应用的许可证尚未调配SPDX标识符，或者应用的是自定义许可证，请应用如下所示的字符串值：

{ "license" : "SEE LICENSE IN <filename>" }

而后<filename>，在包的顶层增加一个名为的文件。

一些旧软件包应用许可证对象或蕴含许可证对象数组的“ licenses”属性：

// Not valid metadata{  "license": {    "type": "ISC",    "url": "https://opensource.org/licenses/ISC"  }}// Not valid metadata{  "licenses": [    {      "type": "MIT",      "url": "https://www.opensource.org/licenses/mit-license.php"    },    {      "type": "Apache-2.0",      "url": "https://opensource.org/licenses/apache2.0.php"    }  ]}

这些款式现已弃用。而是应用SPDX表达式，如下所示：

{ "license": "ISC" }{ "license": "(MIT OR Apache-2.0)" }

最初，如果您不心愿以任何条款授予别人应用公有或未公布软件包的权力：

{ "license": "UNLICENSED" }

还思考进行设置"private": true以避免意外公布。

author, contributors

“作者”是一个人。“贡献者”是一群人。“人员”是具备“名称”字段以及（可选）“ url”和“ email”的对象，如下所示：

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

或者，您能够将所有内容缩短为一个字符串，而后npm会为您解析：

"Barney Rubble <b@rubble.com> (http://barnyrubble.tumblr.com/)"

电子邮件和url都是可选的。

npm还会为您的npm用户信息设置一个顶级“ maintainers”字段。

files

可选的“files”字段是文件模式的数组，形容了将软件包作为依赖项装置时要包含的条目。如果省略files数组，则除主动排除的文件外的所有内容都将蕴含在您的公布中。如果在数组中命名文件夹，则该文件还将包含该文件夹中的文件（除非本节中的另一条规定将疏忽它们）。

您还能够.npmignore在包的根目录或子目录中提供文件，以避免文件被蕴含。在程序包的根目录下，它不会笼罩“files”字段，但在子目录中，它将笼罩。该.npmignore文件的工作形式与一样 .gitignore。如果有.gitignore文件但.npmignore短少文件，.gitignore则将应用的内容。

无论设置如何，总是会蕴含某些文件：

  • package.json
  • README
  • CHANGES / CHANGELOG / HISTORY
  • LICENSE / LICENCE
  • NOTICE
  • “main”字段中的文件

README，CHANGES，LICENSE和NOTICE能够有任何状况下和延长。

相同，某些文件总是被疏忽：

  • .git
  • CVS
  • .svn
  • .hg
  • .lock-wscript
  • .wafpickle-N
  • .*.swp
  • .DS_Store
  • ._*
  • npm-debug.log
  • .npmrc
  • node_modules
  • config.gypi
  • *.orig
  • package-lock.json （改用膨胀包装）

main

模块ID，它是程序的次要入口点。也就是说，如果您的包名为foo，并且用户先装置它，而后执行 require("foo")，则将返回主模块的导出对象。

这应该是绝对于软件包文件夹根目录的模块ID。

对于大多数模块，领有一个主脚本是最有意义的，而通常没有太多其余货色。

bin

许多软件包都具备一个或多个要装置到PATH中的可执行文件。npm使此操作非常容易（实际上，它应用此性能来装置“ npm”可执行文件。）

要应用此性能，请bin在package.json中提供一个字段，该字段是命令名到本地文件名的映射。在装置时，npm会将文件符号链接到 prefix/bin以进行全局装置或./node_modules/.bin/本地装置。

例如，myapp可能具备以下内容：

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

因而，当您装置myapp时，它将创立从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"  }}

请确保您援用的文件以bin结尾 #!/usr/bin/env node，否则脚本将在没有node可执行文件的状况下启动！

man

指定要搁置的单个文件或文件名数组，以供 man程序查找。

如果仅提供一个文件，则将其装置为来自的后果man <pkgname>，而不论其理论文件名如何。例如：

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

将链接./man/doc.1文件，使其成为指标man foo

如果文件名不是以程序包名称结尾的，则应用前缀。所以这：

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

手册文件必须以数字结尾，.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

directorys

CommonJS Packages标准具体介绍了几种应用directories 对象批示软件包构造的办法。如果查看npm的package.json，则会看到它具备doc，lib和man的目录。

lib

通知人们您的lib大部分在哪里。对于lib文件夹，没有什么特地的事件，但这是有用的元信息。

bin

如果在中指定bin目录directories.bin，则将增加该文件夹中的所有文件。

因为该bin指令的工作形式，同时指定 bin门路和设置directories.bin是谬误的。如果要指定单个文件，请应用bin，对于现有bin目录中的所有文件，请应用directories.bin。

man

一个充斥man页的文件夹。糖通过遍历文件夹来生成“ man”数组。

doc

将markdown文件放在这里

example

示例脚本

test

测试

repository

指定代码所在的地位。这对想要奉献的人很有帮忙。如果git repo在GitHub上，则该npm docs 命令将可能找到您。

像这样做：

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

该URL应该是可公开获取（可能是只读）的URL，能够间接将其传递给VCS程序，而无需进行任何批改。它不应是您放入浏览器中的html我的项目页面的url。它用于计算机。

对于GitHub，GitHub gist，Bitbucket或GitLab存储库，您能够应用与以下雷同的快捷方式语法npm install：

"repository": "npm/npm""repository": "github:user/repo""repository": "gist:11081aaa281""repository": "bitbucket:user/repo""repository": "gitlab:user/repo"

scripts

“ scripts”属性是一个字典，其中蕴含在包的生命周期中的各个工夫运行的脚本命令。要害是生命周期事件，该值是在该点运行的命令。

请参阅参考资料，npm-scripts以理解无关编写程序包脚本的更多信息。

config

“ config”对象可用于设置软件包脚本中应用的配置参数，这些配置脚本会在降级期间继续存在。例如，如果一个程序包具备以下内容：

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

而后有一个“开始”命令，该命令随后援用了 npm_package_config_port环境变量，那么用户能够通过执行来笼罩它npm config set foo:port 8001。

无关软件包配置的更多信息，请参见npm-config和npm-scripts。

dependencies

依赖关系在一个简略的对象中指定，该对象将程序包名称映射到版本范畴。版本范畴是一个具备一个或多个以空格分隔的描述符的字符串。依赖关系也能够通过tarball或git URL进行标识。

请不要在您的dependencies物体中搁置测试线束或编译器 。 请参阅devDependencies上面的。

无关指定版本范畴的更多详细信息，请参见semver。

  • version必须version齐全匹配
  • >version 必须大于 version
  • >=version 等等
  • <version
  • <=version
  • ~version“大概等效于版本”请参见semver
  • ^version“与版本兼容”请参见semver
  • 1.2.x 1.2.0、1.2.1等，但不是1.3.0
  • http://... 请参阅上面的“ URL作为依赖项”
  • * 匹配任何版本
  • "" （只是一个空字符串）与 *
  • version1 - version2与雷同>=version1 <=version2。
  • range1 || range2 如果满足range1或range2，则通过。
  • git... 请参阅上面的“将Git URL作为依赖项”
  • user/repo 请参阅上面的“ GitHub URL”
  • tag标记并公布为tag See的特定版本npm-dist-tag
  • 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作为依赖项

您能够指定tarball URL代替版本范畴。

该压缩包将在装置时下载并本地装置到您的软件包中。

Git URL作为依赖项

Git URL的模式为：

<protocol>://[<user>[:<password>]@]<hostname>[:<port>][:][/]<path>[#<commit-ish> | #semver:<semver>]

<protocol>是以下之一git，git+ssh，git+http，git+https，或 git+file。

如果#<commit-ish>提供，它将用于准确克隆该提交。如果commit-ish的格局为#semver:<semver>，<semver>能够是任何无效的semver范畴或确切的版本，并且npm会在近程存储库中查找与该范畴匹配的任何标记或援用，就像对注册表依赖项一样。如果未指定#<commit-ish>或#semver:<semver>，则master应用。

例子：

git+ssh://git@github.com:npm/npm.git#v1.0.27git+ssh://git@github.com:npm/npm#semver:^5.0git+https://isaacs@github.com/npm/npm.gitgit://github.com/npm/npm.git#v1.0.27

GitHub网址

从1.1.65版本开始，您能够将GitHub URL简称为“ foo”：“ user / foo-project”。与git URL一样，commit-ish能够蕴含后缀。例如：

{  "name": "foo",  "version": "0.0.0",  "dependencies": {    "express": "expressjs/express",    "mocha": "mochajs/mocha#4727d357ea",    "module": "user/repo#feature\/branch"  }}

本地门路

从2.0.0版开始，您能够提供蕴含软件包的本地目录的门路。能够应用npm install -S或 npm install --save应用以下任意模式保留本地门路：

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

在这种状况下，它们将被规范化为相对路径并增加到您的中 package.json。例如：

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

此性能对于本地脱机开发和创立须要npm装置的测试很有用，您不想在不打内部服务器的中央装置npm，然而在将程序包公布到公共注册表时不应应用。

devDependencies

如果某人打算在程序中下载和应用您的模块，那么他们可能不心愿或不须要下载并构建您应用的内部测试或文档框架。

在这种状况下，最好将这些其余我的项目映射到一个devDependencies 对象中。

这些货色将在装置时npm link或npm install 从软件包的根目录装置，并且能够像其余任何npm配置参数一样进行治理。无关npm-config更多信息，请参见。

对于不是特定于平台的构建步骤（例如，将CoffeeScript或其余语言编译为JavaScript），请应用prepare 脚本来执行此操作，并使所需的软件包成为devDependency。

例如：

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

该prepare脚本将在公布之前运行，因而用户能够应用该性能而无需他们本人对其进行编译。在开发人员模式下（即在本地运行npm install），它也会同时运行此脚本，以便您能够轻松对其进行测试。

peerDependencies

在某些状况下，您想表白软件包与主机工具或库的兼容性，而不用肯定要require对此主机进行操作。通常将其称为插件。值得注意的是，您的模块可能正在公开主机文档预期和指定的特定接口。

例如：

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

这样能够确保您的软件包tea-latte只能与主机软件包的第二个次要版本一起装置tea。npm install tea-latte可能会产生以下依赖关系图：

├── tea-latte@1.3.5└── tea@2.2.0

留神：peerDependencies如果在依赖关系树中未显式依赖更高版本的npm版本1和2 ，它们将主动装置。在npm的下一个次要版本（npm @ 3）中，将不再是这种状况。您将收到一条正告，提醒您未装置peerDependency。npms 1和2中的行为常常令人困惑，很容易使您陷入依赖天堂，npm旨在尽可能防止这种状况。

尝试装置其余要求抵触的插件会导致谬误。因而，请确保您的插件要求尽可能宽泛，并且不要将其锁定在特定的补丁程序版本中。

假如主机合乎semver，则只有主机软件包次要版本中的更改会毁坏您的插件。因而，如果您应用过主机软件包的每个1.x版本，请应用"^1.0"或"1.x"示意这一点。如果您依赖1.5.2中引入的性能，请应用">= 1.5.2 < 2"。

bundledDependencies

这定义了一组软件包名称，这些软件包名称将在公布软件包时捆绑在一起。

如果您须要在本地保留npm软件包或通过单个文件下载取得它们，则能够通过在bundledDependencies 数组中指定软件包名称并执行来将软件包捆绑在tarball文件中npm pack。

例如：

如果咱们这样定义package.json：

{  "name": "awesome-web-framework",  "version": "1.0.0",  "bundledDependencies": [    "renderized", "super-streams"  ]}

咱们能够awesome-web-framework-1.0.0.tgz通过运行获取文件npm pack。此文件蕴含的依赖关系renderized，并super-streams能够通过执行装置在一个新的我的项目npm install awesome-web-framework-1.0.0.tgz。

如果这是拼写的"bundleDependencies"，那么也很荣幸。

optionalDependencies

如果能够应用依赖项，然而如果找不到或无奈装置npm，则心愿npm持续进行，则能够将其放在optionalDependencies 对象中。这是程序包名称到版本或url的映射，就像 dependencies对象一样。区别在于构建失败不会导致装置失败。

解决依赖关系的缺失依然是程序的责任。例如，如下所示：

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

并且，与依赖项一样，如果您不指定版本（或者如果您指定“ *”作为版本），那么任何版本的节点都能够。

如果您指定“engines”字段，则npm将要求“node”在该列表中的某个地位。如果省略了“ engines”，那么npm只会假如它能够在node上运行。

您还能够应用“engines”字段来指定哪些版本的npm可能正确安装程序。例如：

{ "engines" : { "npm" : "~1.0.20" } }

除非用户设置了engine-strictconfig标记，否则此字段仅供参考，并且仅在将软件包作为依赖项装置时才产生正告。

os

您能够指定模块将在哪些操作系统上运行：

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

您也能够将操作系统列入黑名单而不是白名单，只需在黑名单的操作系统后面加上“！”即可：

"os" : [ "!win32" ]

主机操作系统由 process.platform

只管没有充沛的理由这样做，但容许将其列入黑名单和白名单。

cpu

如果您的代码仅在某些cpu体系结构上运行，则能够指定哪些体系结构。

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

像该os选项一样，您也能够将体系结构列入黑名单：

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

主机架构由 process.arch

private

如果"private": true在package.json中设置，则npm将回绝公布它。

这是避免意外公布公有存储库的办法。如果要确保仅将给定的程序包公布到特定的注册表（例如，外部注册表），请应用publishConfig上面形容的 字典registry在公布时笼罩config参数。

publishConfig

这是将在公布时应用的一组配置值。如果要设置标签，注册表或拜访权限，这特地不便，这样能够确保给定的程序包不标记为“最新”，不公布到全局公共注册表，或者默认状况下作用域模块是公有的。

能够笼罩任何配置值，然而出于公布的目标，当然只有“标签”，“注册表”和“拜访”可能很重要。

请参阅npm-config以查看能够笼罩的配置选项列表。