关于javascript:packagejson配置详解

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

名字就是你的名字。

一些规定：

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

一些技巧：

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

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

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

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

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

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

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

我的项目首页的网址

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

它看起来应该像这样：

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

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

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

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

如果您应用的是通用许可证，例如 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 以避免意外公布。

“作者”是一个人。“贡献者”是一群人。“人员”是具备“名称”字段以及（可选）“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 数组，则除主动排除的文件外的所有内容都将蕴含在您的公布中。如果在数组中命名文件夹，则该文件还将包含该文件夹中的文件（除非本节中的另一条规定将疏忽它们）。

您还能够 .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（改用膨胀包装）

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

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

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

许多软件包都具备一个或多个要装置到 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 <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

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

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

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

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

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

将 markdown 文件放在这里

示例脚本

测试

指定代码所在的地位。这对想要奉献的人很有帮忙。如果 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”属性是一个字典，其中蕴含在包的生命周期中的各个工夫运行的脚本命令。要害是生命周期事件，该值是在该点运行的命令。

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

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

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

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

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

依赖关系在一个简略的对象中指定，该对象将程序包名称映射到版本范畴。版本范畴是一个具备一个或多个以空格分隔的描述符的字符串。依赖关系也能够通过 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"
  }
}

您能够指定 tarball 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.27
git+ssh://git@github.com:npm/npm#semver:^5.0
git+https://isaacs@github.com/npm/npm.git
git://github.com/npm/npm.git#v1.0.27

从 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 对象中。

这些货色将在装置时 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），它也会同时运行此脚本，以便您能够轻松对其进行测试。

在某些状况下，您想表白软件包与主机工具或库的兼容性，而不用肯定要 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"。

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

如果您须要在本地保留 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"，那么也很荣幸。

如果能够应用依赖项，然而如果找不到或无奈装置 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，因而通常最好只放在一个地位。

您能够指定您的货色能够在其上运行的 node 的版本：

{"engines" : { "node" : ">=0.10.3 <0.12"} }

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

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

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

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

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

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

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

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

"os" : ["!win32"]

主机操作系统由 process.platform

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

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

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

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

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

主机架构由 process.arch

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

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

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

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

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

关于javascript:packagejson配置详解

name

version

description

keywords

homepage

bugs

license

author, contributors

files

main

bin

man

directorys

lib

bin

man

doc

example

test

repository

scripts

config

dependencies

URL 作为依赖项

Git URL 作为依赖项

GitHub 网址

本地门路

devDependencies

peerDependencies

bundledDependencies

optionalDependencies

engines

os

cpu

private

publishConfig