Node.js中package.json详解

1. name（名称）

如果你计划发布你的包，package.json 中最重要的字段是 name 和 version，因为它们是必需的。name 和 version 共同组成一个假定完全唯一的标识符。包的更改应伴随版本号的更新。如果你不打算发布包，那么 name 和 version 字段是可选的。

name 就是你包的名称。

一些规则：

• 名称必须少于或等于 214 个字符。这包括范围包的范围部分。

• 范围包的名称可以以点（.）或下划线（_）开头。如果没有范围，则不允许这样做。

• 新包的名称不能包含大写字母。

• 名称将成为 URL 的一部分、命令行中的参数以及文件名。因此，名称不能包含任何非 URL 安全的字符。

一些建议：

• 不要使用与 Node 核心模块相同的名称。

• 不要在名称中使用 "js" 或 "node"。因为你正在编写 package.json 文件，默认情况下它是 JavaScript 项目，你可以通过 engines 字段指定运行环境。

• 名称可能会被传递给 require()，因此它应短小且具有描述性。

• 在命名之前，建议检查 npm 注册表，以确认是否已经存在相同名称的包：https://www.npmjs.com/

• 名称可以选择性地添加范围前缀，例如 @myorg/mypackage。详细信息请参阅 scope

2. version（版本）

如果你计划发布包，package.json 中最重要的字段是 name 和 version，因为它们是必须的。name 和 version 共同构成唯一的标识符。包的更改应伴随版本号的更新。如果你不打算发布包，那么 name 和 version 字段是可选的。

版本号必须能够通过node-semver 解析，它作为 npm 的依赖项捆绑在一起，当然你也可以通过 npm install semver 来单独使用它。

3. description（描述）

为包添加描述。它是一个字符串，有助于用户通过 npm search 搜索到你的包。

4. keywords（关键词）

为包添加关键词。它是一个字符串数组，能够帮助用户通过 npm search 搜索到你的包。

5. homepage（主页）

项目主页的 URL。

 "homepage": "https://github.com/owner/project#readme"

6. bugs（问题报告）

项目的问题跟踪 URL 和/或用于报告问题的电子邮件地址。当人们遇到包的问题时，这些信息很有帮助。

应该是这样的格式：

{"bugs": {"url": "https://github.com/owner/project/issues","email": "[e-mail]"}
}

你可以只指定 URL，也可以同时指定 URL 和电子邮件。如果只想提供 URL，可以将 bugs 字段值写成一个简单的字符串而不是对象。

如果提供了 URL，它将被 npm bugs 命令使用。

7. 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" 属性：

{// 非有效元数据"license": {"type": "ISC","url": "https://opensource.org/licenses/ISC"}
}{// 非有效元数据"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，以防止包意外发布。

8. people fields: author, contributors（人员字段：作者、贡献者）

author 表示一个人，contributors 是一个人员数组。一个 "person" 是一个包含 name 字段的对象，可选的 email 和 url 字段，如下所示：

{"name": "Barney Rubble","email": "[e-mail]","url": "http://barnyrubble.tumblr.com/"
}

或者你可以将其简写为一个字符串，npm 会自动解析它：

{"author": "Barney Rubble <[e-mail]> (http://barnyrubble.tumblr.com/)"
}

无论是 email 还是 url 都是可选的。

npm 还会使用你的 npm 用户信息设置顶级 maintainers 字段。

9. funding（资助）

你可以指定一个包含资助信息的 URL，提供用于帮助资助开发的信息。它可以是一个字符串 URL，或者是一个对象数组和字符串 URL 的组合。

{"funding": {"type": "individual","url": "http://example.com/donate"}
}

{"funding": {"type": "patreon","url": "https://www.patreon.com/my-account"}
}

{"funding": "http://example.com/donate"
}

{"funding": [{"type": "individual","url": "http://example.com/donate"},"http://example.com/donateAlso",{"type": "patreon","url": "https://www.patreon.com/my-account"}]
}

用户可以使用 npm fund 子命令列出项目依赖项（直接或间接）的资助 URL。你还可以使用 npm fund <projectname> 来访问每个资助 URL（如果有多个 URL，则会访问第一个）。

10. files（文件）

可选的 files 字段是一个文件模式数组，描述当你的包作为依赖项安装时应包含的条目。文件模式的语法类似于 .gitignore，但相反：包括的文件、目录或通配符模式（如 *，**/* 等）将在打包时被包含。省略该字段将默认为 ["*"]，这意味着它将包含所有文件。

某些特殊文件和目录也会被包含或排除，无论它们是否存在于 files 数组中。

你还可以在包的根目录或子目录中提供 .npmignore 文件，该文件可以防止某些文件被包含。在根目录中，它不会覆盖 files 字段，但在子目录中会覆盖。.npmignore 文件的工作方式与 .gitignore 类似。如果存在 .gitignore 文件，但没有 .npmignore 文件，.gitignore 的内容将被使用。

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

• package.json

• README

• LICENSE / LICENCE

• main 字段中的文件

• bin 字段中的文件

README 和 LICENSE 可以具有任意大小写和扩展名。

某些文件总是默认被忽略：

• *.orig

• *.swp

• .DS_Store

• ._*

• .git

• .hg

• .lock-wscript

• .npmrc

• .svn

• .wafpickle

• CVS

• config.gypi

• node_modules

• npm-debug.log

• package-lock.json（如果希望它被发布，请使用 npm-shrinkwrap.json）

• pnpm-lock.yaml

• yarn.lock

大多数这些被忽略的文件可以通过在 files 字段中明确包含来包含，但以下文件不能被包含：

• .git

• .npmrc

• node_modules

• package-lock.json

• pnpm-lock.yaml

• yarn.lock

这些文件无法被包含。

11. exports（导出）

exports 提供了一种现代替代 main 的方式，允许定义多个入口点，支持环境之间的条件解析，并防止除了 exports 定义的入口点以外的任何其他入口点被访问。这种封装允许模块作者明确定义包的公共接口。有关更多详细信息，请参阅 Node.js 文档中的包入口点。

12. main（主文件）

main 字段是一个模块 ID，表示程序的主要入口点。也就是说，如果你的包名为 foo，用户安装了它并执行了 require("foo")，则会返回你 main 模块的 exports 对象。

这应该是相对于包根目录的模块路径。

对于大多数模块，最合理的做法是提供一个主要脚本，通常没有其他文件。

如果 main 未设置，则默认使用包根目录中的 index.js。

13. browser（浏览器）

如果你的模块是为了客户端使用的，browser 字段应该被用于替代 main 字段。这有助于提示用户模块可能依赖于 Node.js 模块中不可用的浏览器原生 API。

14. bin（可执行文件）

许多包有一个或多个希望安装到 PATH 中的可执行文件。npm 让这件事变得非常容易，npm 自己就是通过这种功能来安装的。

要使用它，在 package.json 中提供一个 bin 字段，它是命令名称到本地文件名的映射。当包被全局安装时，该文件将被接到全局 bin 目录中，或者在 Windows 上创建一个 cmd 文件，执行 bin 字段中指定的文件，从而可以通过 name 或 name.cmd 运行它们。当该包作为另一个包的依赖项安装时，该文件将被链接，使得它可以直接通过 npm exec 或其他脚本中的 npm run-script 命令使用。

例如，myapp 可以这样定义：

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

因此，当你安装 myapp 时，在类 Unix 操作系统中，它会从 cli.js 脚本创建一个符号链接到 /usr/local/bin/myapp，在 Windows 中，它会创建一个 cmd 文件，通常位于 C:\Users\{Username}\AppData\Roaming\npm\myapp.cmd，它会运行 cli.js 脚本。

如果你有一个可执行文件，并且它的名称应该与包的名称相同，那么你可以将其作为字符串提供。例如：

{"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 可执行文件启动。

注意，你也可以使用 directories.bin字段设置可执行文件。

15. 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"]
}

将创建 foo.1 和 bar.1的条目。

手册文件必须以数字结尾，并且如果它们被压缩，则可以选择 .gz 后缀。数字决定了文件安装到哪个手册部分。

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

将创建 foo.1 和 foo.2的条目。

16. directories（目录）

CommonJS Packages 规范详细说明了如何使用 directories 对象指示包的结构。如果你查看 npm 的 package.json，你会发现它有 doc、lib 和 man 目录。

未来，此信息可能会以其他创新方式使用。

16.1. directories.bin

如果你在 directories.bin 中指定了一个 bin 目录，该文件夹中的所有文件都将被添加。

由于 bin 指令的工作方式，指定 bin 路径并同时设置 directories.bin 是一个错误。如果你想要指定单个文件，请使用 bin，如果要包含现有 bin 目录中的所有文件，请使用 directories.bin。

16.2. directories.man

一个包含手册页面的文件夹。通过遍历文件夹生成一个 "man" 数组的语法糖。

17. repository（仓库）

指定代码存放的位置。这对于想要贡献的人来说很有帮助。如果 git 仓库在 GitHub 上，那么 npm repo 命令将能够找到你。

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

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"

如果 package.json 不在项目的根目录中（例如，如果它是 monorepo 的一部分），你可以指定它所在的目录：

"repository": {"type": "git","url": "git+https://github.com/npm/cli.git","directory": "workspaces/libnpmpublish"
}

18. scripts (脚本)

scripts 属性是一个字典，包含在包生命周期的不同阶段运行的脚本命令。键是生命周期事件，值是运行的命令。

更多关于编写包脚本的内容，请参阅 scripts。

19. config (配置)

config 对象可以用来设置包脚本中使用的配置参数，并在升级时保留。例如，如果包有以下内容：

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

它还可以有一个 start 命令，引用 npm_package_config_port 环境变量。

20. dependencies（依赖项）

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://... 参见下文中的 'URLs as Dependencies'。

• * 匹配任何版本。

• ""（空字符串）等同于 *。

• version1 - version2 等同于 >=version1 <=version2 。

• range1 || range2 如果满足 range1 或 range2，则通过。

• git ... 参见下文中的 'Git URLs as Dependencies'。

• user/repo 参见下文中的 'GitHub URLs'。

• tag 指定标记并发布为 tag 的特定版本。参见 npm dist-tag 

• path/path/path 参见下文中的 'Local Paths'。

• npm:@scope/pkg@version 自定义别名。参见 package-spec

以下都是有效的：

{"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","dy1": "file:../dy1","kpg": "npm:pkg@1.0.0"}
}

20.1. URLs as Dependencies（URL 作为依赖项）

你可以用 tarball URL 替代版本范围。

在安装时，该 tarball 将被下载并本地安装到你的包中。

20.2. Git URLs as Dependencies（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 将查找匹配该范围的标签或 refs，就像它为注册表依赖项做的一样。如果既没有指定 #commit-ish 也没有指定 #semver:semver，则使用默认分支。

git+ssh://[e-mail]:npm/cli.git#v1.0.27
git+ssh://[e-mail]/npm/cli#semver:^5.0
git+https://[e-mail]/npm/cli.git
git://github.com/npm/cli.git#v1.0.27

当从 git 仓库安装时，package.json 中的某些字段将导致 npm 认为需要进行构建。为此，npm 将克隆你的仓库到一个临时目录，安装其所有依赖项，运行相关脚本，然后打包并安装结果目录。

如果你的 git 依赖项使用了 workspaces，或者存在以下脚本中的任何一个，npm 将进行这种流程：

• build

• prepare

• prepack

• preinstall

• install

• postinstall

如果你的 git 仓库包含预构建的产物，你可能希望确保没有定义这些脚本，否则每次安装时都会重新构建依赖项。

20.3. GitHub URLs（GitHub URL）

从版本 1.1.65 开始，你可以仅使用 "foo": "user/foo-project" 的方式引用 GitHub URL。就像 git URL 一样，可以包含 <commit-ish>

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

20.4. Local Paths（本地路径）

从版本 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 install 时不会安装其自己的依赖项。你必须从本地路径内部运行 npm install。

21. devDependencies（开发依赖）

如果有人计划在他们的程序中下载并使用你的模块，那么他们可能不希望或不需要下载和构建你使用的外部测试或文档框架。

在这种情况下，最好将这些额外的项目映射到 devDependencies 对象中。

这些项目在执行 npm link 或从包根目录运行 npm install 时会被安装，并且可以像任何其他 npm 配置参数一样进行管理。有关更多信息，请参阅 config。

对于与平台无关的构建步骤，例如将 CoffeeScript 或其他语言编译为 JavaScript，使用 prepare 脚本来完成此操作，并将所需的包作为开发依赖项。

{"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 脚本将在发布前运行，这样用户可以在不需要自己编译的情况下使用功能。在开发模式下，此脚本也会运行，以便于测试。

22. 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

在 npm 版本 3 到 6 之间，peerDependencies 不会自动安装，如果发现无效版本的对等依赖项，npm 将发出警告。从 npm v7 开始，peerDependencies 默认会被安装。

尝试安装另一个有冲突要求的插件可能会导致错误，特别是在依赖树无法正确解析时。因此，确保插件的要求尽可能宽泛，并且不要将其锁定为特定补丁版本。

假设主包遵循 semver，只有主包的大版本号变更才会破坏插件。因此，如果你的插件与主包的每个 1.x 版本都兼容，请使用 "^1.0" 或 "1.x" 来表达这一点。如果你依赖于 1.5.2 中引入的功能，请使用 "^1.5.2"。

23. peerDependenciesMeta（对等依赖元信息）

peerDependenciesMeta 字段为 npm 提供了更多关于如何使用对等依赖的信息。特别是，它允许将对等依赖标记为可选。npm 不会自动安装可选的对等依赖。这样，你可以与各种主包集成和交互，而无需安装所有主包。

{"name": "tea-latte","version": "1.3.5","peerDependencies": {"tea": "2.x","soy-milk": "1.2"},"peerDependenciesMeta": {"soy-milk": {"optional": true}}
}

24. bundleDependencies（捆绑依赖项）

此字段定义了发布包时要捆绑的包名数组。

在某些情况下，你需要本地保留 npm 包或通过单个文件下载它们。你可以通过在 bundleDependencies 数组中指定包名并执行 npm pack 来实现此目的。

如果我们定义了一个如下所示的 package.json 文件：

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

运行 npm pack 将生成 awesome-web-framework-1.0.0.tgz 文件。该文件包含 renderized 和 super-streams 依赖项，可以通过执行 npm install awesome-web-framework-1.0.0.tgz 在新项目中安装这些依赖项。请注意，包名不包括任何版本信息，因为这些信息在 dependencies 中已经指定。

如果将其拼写为 "bundledDependencies"，它也会被接受。或者，"bundleDependencies" 也可以定义为布尔值。true 表示将捆绑所有依赖项，false 表示不捆绑任何依赖项。

25. optionalDependencies（可选依赖）

如果某个依赖项可以使用，但你希望即使它找不到或安装失败，npm 也能继续安装，那么可以将其放在 optionalDependencies 对象中。这个对象的结构与 dependencies 类似，是包名到版本或 URL 的映射。区别在于构建失败不会导致安装失败。运行 npm install --omit=optional 将阻止安装这些依赖项。

仍然是你的程序需要处理没有依赖项的情况。例如，可以这样做：

try {var foo = require('foo')var fooversion = require('foo/package.json').version
} catch (er) {foo = null
}
if ( notGoodFooversion(fooversion) ) {foo = null
}// ..然后在你的程序的某处..if (foo) {foo.doFooThings()
}

optionalDependencies 中的条目将覆盖 dependencies 中相同名称的条目，因此最好只在一个地方声明依赖项。

26. overrides（覆盖）

如果你需要对依赖项的依赖项进行特定更改，例如替换具有已知安全问题的依赖版本、将现有依赖项替换为分支版本，或者确保某个包的相同版本在所有地方都被使用，那么你可以添加一个覆盖。

覆盖允许将依赖树中的包替换为另一个版本或完全替换为另一个包。这些更改可以指定得非常具体或非常宽泛。

覆盖仅在项目的根 package.json 文件中生效。已安装依赖项（包括 workspaces）中的覆盖不会被考虑。已发布的包可以通过固定依赖项或使用 npm-shrinkwrap.json 文件来控制其解析。

要确保包 foo 始终安装为版本 1.0.0，无论你的依赖项依赖于哪个版本：

{"overrides": {"foo": "1.0.0"}
}

上面是简写形式，完整的对象形式允许覆盖包本身以及其子项。这将确保 foo 始终是 1.0.0，同时也会让 bar 在任何深度上始终是 1.0.0：

{"overrides": {"foo": {".": "1.0.0","bar": "1.0.0"}}
}

仅当 foo 是包 bar 的子包（或孙子包、曾孙子包等）时，才覆盖 foo 为 1.0.0：

{"overrides": {"bar": {"foo": "1.0.0"}}
}

键可以嵌套到任意长度。仅当 foo 是 bar 的子包并且 bar 是 baz 的子包时，才覆盖 foo：

{"overrides": {"baz": {"bar": {"foo": "1.0.0"}}}

覆盖的键还可以包含版本或版本范围。仅当 foo 是 bar@2.0.0 的子包时，将 foo 覆盖为 1.0.0：

{"overrides": {"bar@2.0.0": {"foo": "1.0.0"}}
}

除非依赖项和覆盖本身具有相同的规范，否则你不能为你直接依赖的包设置覆盖。为了让这种限制更容易处理，覆盖可以定义为对直接依赖项的规范引用，通过在你希望版本匹配的包名前添加 $ ：

{"dependencies": {"foo": "^1.0.0"},"overrides": {// 错误，将抛出 OVERRIDE 错误// "foo": "^2.0.0"// 正确，规范匹配，因此允许覆盖// "foo": "^1.0.0"// 最佳，覆盖定义为对依赖项的引用"foo": "$foo",// 被引用的包不需要与被覆盖的包相同"bar": "$foo"}
}

27. engines（引擎）

你可以指定包兼容的 Node.js 版本：

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

与依赖项类似，如果你不指定版本（或者指定 * 作为版本），那么任何版本的 Node.js 都可以使用。

你还可以使用 engines 字段指定能够正确安装你程序的 npm 版本。例如：

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

除非用户设置了engine-strict 配置标志，否则该字段仅为建议用途，当你的包作为依赖项安装时只会产生警告。

28. os（操作系统）

你可以指定模块运行在哪些操作系统上：

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

你也可以阻止特定操作系统，只需在阻止的操作系统前加 ！

{"os": ["!win32"]
}

主机操作系统通过 process.platform 确定。

你可以同时阻止和允许某个操作系统，尽管这没有什么意义。

29. cpu（CPU 架构）

如果你的代码只能在某些 CPU 架构上运行，你可以指定这些架构：

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

与 os 选项类似，你也可以阻止某些架构：

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

主机架构通过 process.arch 确定。

30. private（私有）

如果你在 package.json 中设置 "private": true，npm 将拒绝发布该包。

这是防止私有仓库意外发布的方式。如果你希望确保某个包只发布到特定的注册表（例如，内部注册表），请使用下面描述的 publishConfig 字典，在发布时覆盖 registry 配置参数。

31. publishConfig（发布配置）

这是发布时使用的一组配置值。如果你希望设置标记、注册表或访问权限，这特别方便。你可以确保给定的包不会标记为 "latest"，不会发布到全局公共注册表，或者默认情况下范围包是私有的。

请参阅 config 以查看可覆盖的配置选项列表。

32. workspaces（工作区）

可选的 workspaces 字段是一个文件模式数组，描述了安装客户端应在本地文件系统中查找的每个工作区，这些工作区需要链接到顶级 node_modules 文件夹。

它可以描述要用作工作区的文件夹的直接路径，也可以定义可以解析为这些文件夹的通配符。

在以下示例中，位于 ./packages 文件夹中的所有文件夹将被视为工作区，只要它们包含有效的 package.json 文件：

{"name": "workspace-example","workspaces": ["./packages/*"]
}

有关更多示例，请参阅 workspaces。

33. DEFAULT VALUES（默认值）

npm 会根据包内容默认一些值。

"scripts": {"start": "node server.js"}

如果包根目录中有一个 server.js 文件，npm 会默认将启动命令设置为 node server.js 。

"scripts":{"install": "node-gyp rebuild"}

如果包根目录中有一个 binding.gyp 文件，并且你没有定义 install 或 preinstall 脚本，npm 会默认使用 node-gyp 进行编译。

"contributors": [...]

如果包根目录中有一个 AUTHORS 文件，npm 会将每一行视为 Name <email> (url) 格式，其中 email 和 url 是可选的。以 # 开头或空行的行将被忽略。