npm 指南：Node.js 包管理器

在开发网站和 Web 应用程序时，JavaScript 很容易成为最常用的语言。 资源之多令人震惊，可用图书馆的数量更是惊人。

起初，这些库很少且易于维护； 但是，很快就会出现依赖地狱，需要更成熟的解决方案。

进入 Node Package Manager (npm)——一个 JavaScript 包管理器，最显着地与 Node.js 结合使用，尽管它也可以独立使用。 它使您可以对项目的依赖项进行出色的控制，并提供了一种为开源世界做出贡献的好方法。

您可以通过简单地运行npm install <package name>并将其注入到您的 JavaScript 文件中开始。

想要安装特定版本？ 没问题。 运行npm install <package name>@1.2.3 。

想要全局安装包（如 Mocha 或 Angular-CLI）？ 只需像这样添加-g ： npm install -g angular-cli mocha 。

诚然，大多数用例都在 npm 安装时停止，不需要其他任何东西。 然而，npm 有很多额外的功能，我将引导你完成，重点介绍我认为必不可少的、真正有用的或非常棒的那些。

CLI 命令

CLI 是用户大部分时间与 npm 交互的地方，它的帮助界面实际上很有帮助。

查询帮助 ( npm help ) 会输出一整套选项，运行npm help-search <searchText>会直接从 npm 降价中为您提供搜索结果列表。

以下是突出的核心命令。

• install ：这里提到它是因为它在使用 npm 时绝对必要。 用于在本地或全局安装新包（添加-g时）或安装package.json文件中列出的依赖项（稍后会详细介绍）。

• uninstall ：这也是必不可少的。 它用于在本地或全局（添加-g时）从node_modules目录中清除特定包。

• access ：这是上下文 npm-organizations 和范围（私有）包中 npm 用户权限管理员的游乐场。 非常强大的东西。 与adduser 、 owner 、 team等一起使用，它可以细粒度地控制谁可以访问什么。

• bin : 包到底安装在哪里？ 运行此命令以查看绝对文件路径。

• cache ：如果你从 npm left、right 和 center 开始安装包，这个命令非常有用。 使用ls子命令调用它以查看本地缓存包的列表，或者使用clean子命令清除缓存中的所有包。 回到 npm 注册表仍然有点不稳定的时候，这对于回到稳定的环境或在您没有正确设置 npm 权限时重置事物至关重要。

• config ：稍后我们将介绍不同的配置选项，但此命令主要处理通过使用set 、 get或delete子命令在本地或全局配置文件中持久化配置属性。

• dedupe或ddp ：当长时间从事项目并直接从 npm 安装包时，此命令将遍历本地包树并尝试简化依赖关系。

• link ：当您开发自己的 npm 包时，这允许您创建指向全局上下文的符号链接，以便可以对其进行测试，就好像它是从 npm 注册表全局安装一样。 例如，如果您在 node 中编写一个全局安装 CLI 的组装工具，您可以运行此命令并测试您的 CLI 的行为，而无需先部署它。

• ls ：它用于以树状结构可视化包依赖关系及其依赖关系。 看起来很酷，并且对于与其他项目的比较也很有用。

• outdated ：这用于评估已安装依赖项的当前状态以及它们是否已过时。 在根依赖列表长达数百行的项目中，手动检查包几乎是不可能的。 将-g --depth=0添加到此命令中，您还可以检查全局安装的软件包。

• publish ：在为 npm 开发自己的包时，此命令是必不可少的。 顾名思义，它确实如此； 它将你的包发布到 npm 注册表。

• search ：使用它在注册表中搜索包含第三个参数中提供的文本的所有包。

• shrinkwrap ：简而言之，此命令允许您按顺序锁定包中的特定依赖项版本，以便宽松的 semver（语义版本控制）编号不会破坏生产代码。

• star ：你真的喜欢你正在使用的包吗？ 使用此命令直接从终端表达您的赞赏，然后反映在 npm 注册表上的包页面上。

• update ：这通常遵循outdated的命令来更新任何过时的包。

• version ：这为您提供了一种简写方式来提升package.json版本属性，并合而为一地执行 git 标记。

请注意，这些命令中的大多数都可以采用子命令和/或配置，并且此列表绝不是对 CLI 的最终讨论。

npm-配置

配置是 npm 的主要部分，可以通过多种方式设置配置变量。

通过 CLI 和环境变量进行配置

首先，可以从终端通过 CLI 设置配置。

通常它看起来像这样： npm <command> --<configuration option> [<optional value>] 。

如果未指定该值，则该选项将默认设置为 true。

例如，假设您正在处理一个作用域（私有）npm 包，并且您决定将其发布为公共包。

这很容易通过将--access=public附加到您的publish命令来完成。 如果我们没有将属性指定为公共，则默认为受限（私有）。

像这样附加到其他命令的配置不会随处保留，因此通过 CLI 设置一组配置会变得很烦人。

在这些情况下，使用环境变量设置配置可能会更好。

任何带有npm_config_前缀的环境变量都将用于配置 npm。

例如： export npm_config_registry=localhost:4321将全局设置注册表配置选项，当执行 npm 时，它将使用位于 localhost 端口 4321 上的 npm 注册表。

通过 npmrc 文件进行配置

您还可以使用特殊的.npmrc文件设置配置选项，该文件可以根据您的要求设置为不同的级别：

• 项目级别：在项目代码及其package.json文件的根目录中，通常是path/to/project/.npmrc
• 用户级别：配置特定用户账户的目录，一般为~/.npmrc
• 全局级别：npm 查找全局配置的目录，通常$PREFIX/etc/npmrc
• 内置级别：小心。 此配置不仅是全局的，而且也是 npm 源代码的一部分，最佳实践建议（实际上是要求）我们不要更改我们不负责维护的代码。 它通常可以在/path/to/npm/npmrc中找到。

.npmrc文件中的配置设置可以使用 CLI 通过运行以下格式的命令进行修改和持久化： npm config set <key> <value> 。

例如，您可以运行npm config set access public以使作用域（私有）包的发布配置永久公开。

默认情况下，此命令将在本地持久化配置（如上所述的用户级别配置），但您可以添加-g以将其全局持久化。

当需要在项目级别或内置级别进行持久配置时，必须使用文本编辑器修改.npmrc文件。

通过 package.json 配置

最后，可以从package.json文件中设置配置。 但是，这很少使用（只有在明确需要时才应使用），因为项目级别的.npmrc文件是设置包配置的传统首选位置。

值得注意的配置设置

• access ：如上所述，它用于设置权限。

• always-auth ：请务必注意，此设置默认为 false。 当它设置为 true 时，npm 在联系注册表时将始终要求身份验证。

• ca ：默认为 npm 证书颁发机构 (CA)。 可以将其更改为 null 以仅允许访问已知注册商，或更改为特定 CA 证书以仅授予对该特定注册商的访问权限。 此设置以及cafile 、 cert和strict-ssl很少使用，但谈到 npm 的安全性和可靠性方面，让您可以放心地知道您正在安装的软件包来自您期望的源。

• color ：默认为 true，通过着色stdout文件描述符允许的标准输出，让您摆脱终端的标准黯淡。 如果设置为 false，则终端仍然是枯燥的。 当它设置为always时，它总是以彩色输出。

• depth ：此设置允许通过指定执行的深度来精细控制使用递归命令（例如ls和outdated ）看到的内容。 值 0 将仅评估第一级依赖关系，而无穷大（默认值）将导致评估所有级别的依赖关系。 此规则的例外是与outdated一起使用时； 在这种情况下，无穷大被解释为 0 以确保更相关的输出。

• dev ：默认情况下设置为 false，但是当设置为 true 时（执行npm install时） package.json文件中的所有开发依赖项将与正常依赖项一起安装。

• dry-run ：当此设置设置为 true 时，npm 不会对您的包进行任何更改，而是会告诉您它会做什么。 这在运行某些命令时非常有用，例如dedupe或update 。

  

• git-tag-version ：默认设置为 true。 运行npm version命令时，此设置在 git 中标记版本。 如果您使用 npm 作为在 git 中标记了版本的大型项目的包管理器，它可以节省您的时间，并记得为您更新package.json文件。

• loglevel ：默认设置为warn ，在运行 npm 命令时会给出错误和警告输出。 其他设置包括silent ，它不提供输出； error ，仅将错误记录到输出； http ，只通告http请求错误； info ，用于需要信息输出）； verbose ，几乎记录所有内容； 和silly ，就像名字所暗示的那样，它给出了一个愚蠢的输出量，然后是一些。

• production ：当它设置为 true 时，npm 会相应地采取行动并在生产模式下运行所有​​命令。 这意味着不会安装开发或可选依赖项，也不会执行任何与开发相关的任务。

• rollback ：设置为 true 时，将删除所有失败的安装。 当依赖项安装失败时，这会派上用场。 根据您的日志记录级别，您应该能够查看哪些安装失败，记下这些，然后运行npm install命令并将回滚选项设置为 true。 然后使用您的笔记和试运行安装（如上所述），您可以调试问题。

• save : When installing a package directly from the registry, you can append –save to the command which will add the installed package to the dependencies option in the package.json file. For example, file. For example, npm install lodash` 会将 lodash 添加到您的依赖项中。

• save-dev : 类似于 save 配置选项，在安装包时添加--save-dev ，然后会添加到package.json文件中的 devDependencies 选项中。

• save-optional : 与 save 配置选项类似，在安装包时添加--save-optional ，然后将其添加到package.json文件中的 optionalDependencies 选项中。

• save-exact ：安装包时， save 、 save-dev和save-optional选项通过使用 semver 范围运算符将已安装的包插入其各自的属性来修改package.json文件。 当调用值为 true 的“save-exact”配置设置时，结合上述设置之一，使用特定版本号，忽略 semver 范围。

• save-prefix ：这会在使用save 、 save-dev或save-optional时设置 semver 范围运算符。 默认值为^ ，允许在安装时对包进行小幅升级。 这可以设置为任何有效的前缀 semver 范围运算符。

• tag-version-prefix ：常规默认值是v ，指定在运行npm version时添加到 git tag version 的内容。

使用 npm 更新 npm

你也可以使用 npm 来更新自己。

只需运行npm install -g npm@latest ，npm 就会更新到最新的稳定版本。 重要的是要注意每个版本的 Node.js 都附带一个特定版本的 npm，根据我的经验，你不应该过多地混淆这种配对。

归根结底，我的建议是坚持按预期配对。

将 npm 用作独立工具时，请确保您了解使用您选择的任何版本的含义。 有一个很棒的工具可以在名为 nvm 的同一系统上管理不同的 Node.js 版本（以及 npm 版本）。

package.json 文件

package.json文件是将所有内容链接在一起的关键元素。

这是将包发布到 npm 注册表的要求，也是依赖项的管理部分发挥作用的地方。

它有两个必填字段，即“名称”和“版本”，这些属性一起应该是一个唯一标识符。

name 字段应遵守 npm 命名文档中定义的某些规则，version 字段受 semver 规范的约束。

除此之外，您可以拥有一英里长的依赖项列表，并使用 semver 版本和范围运算符定义要用于每个依赖项的特定版本。 这是其他值得注意的属性的列表。

“主要的”

“main” 定义应用程序的入口点，默认为index.js 。 根据约定或您的框架，它可能是app.js或main.js 。 当然，您可以随意制作。

“脚本”

这是一个被低估的财产。

首先，它可以用来做预发布的事情。

其次，它提供了一个可以为一系列常用命令设置别名的地方，包括构建任务（在 gulp 或 grunt 中定义）、触发安装其他依赖项（使用类似 bower）、使用 webpack 启动开发服务器或运行一组 bash 命令。

“依赖”

此属性是您的应用程序所需的包列表，以及兼容的 semver 编号。 这是一个值得注意的属性，因为可以在安装本地软件包时从终端进行修改。

这是通过在npm install命令末尾添加--save （或简写-S ）来完成的。

执行此操作时，新安装的包将添加到package.json文件中的依赖项列表中。

同样，也可以通过在运行npm uninstall命令时添加--save来删除依赖项。

了解每个依赖项的 semver 版本控制模式及其含义非常重要。

如果 semver 规则过于严格，您将失去新功能和改进，而如果 semver 规则过于宽松，则可以沿线安装软件包的破坏版本。

损坏的软件包安装可能很难解决，尤其是在使用软件包的缩小版本时。

“开发依赖”

与 dependencies 属性分开，“devDependencies”属性允许您定义仅在开发阶段使用且生产构建不需要的依赖项（如 ESLint、grunt-contrib 包和 Protractor）。 与依赖项一样，可以通过在npm install命令或npm uninstall命令的末尾添加--save-dev （或简写-D ）从终端修改此属性。 同样的注意事项也适用于依赖项下提到的版本控制。

“斌”

您可以在此处指定包的可执行文件，例如 CLI 实用程序的路径。 此属性告诉 npm 在安装包时为可执行文件创建本地或全局符号链接。

“配置”

如前所述，这是您通过package.json文件定义配置设置的地方。

“私人的”

当设置为 true 时，npm 将拒绝发布包。

这不应与访问配置设置相混淆。

当您有一个使用 npm 及其package.json的项目但它不打算发布到 npm 注册表（无论是作用域的还是公共的）时，这是一个方便的设置。

如果您的意图发生变化，只需将设置更改为 false，您就可以发布您的包。

自定义属性

package.json文件也接受自定义属性，只要名称尚未定义或保留。

开发你自己的 npm 包

npm 生态系统充满了包，由世界各地成千上万的不同开发人员编写。 每个都解决某种问题，提供抽象，或呈现某事的实现。

很有可能，在某些时候，您也会想要开发自己的包来分享。

首先，您需要创建一个package.json文件，其中包含“name”和“version”所需的最少属性，然后是“main”属性来指定入口点，例如 index.js。

在 index.js 文件中编写您的代码，使用您的 npm 用户帐户登录，或者从终端创建一个新用户，然后您就可以将其发布到 npm 注册表了。

包可以是公共的或私有的。

公共软件包可以免费发布，并且可供所有人使用。

私有包，称为作用域包，只有在您向私有模块用户付费的情况下才能发布，并且它们可以通过附加在包名称前面的不同@username/来标识。

范围包也可以通过使用--access=public调用publish命令来公开发布。

此外，如果您花费更多时间扩展和改进包的代码库，并且是时候发布新版本了，您只需在package.json中更改包的版本（根据 semver 规则和约定）文件并输入npm publish 。

您还可以使用命令行界面并调用npm version <update_type> ，其中 update_type 是patch 、 minor或major ，如 semver 所述，然后会自动增加package.json文件中的版本号。

npm 组织

同样，这方面的 npm 文档非常好，重复他们的话是徒劳的。

关于 npm 上下文中的组织可以说的是，它是非常细粒度的，如果管理得当，大型团队和个人，在一个名称下处理范围或公共包，可以得到很好的管理和限制。

虽然掌握起来很复杂，但它非常有益。

npm 的力量

归根结底，npm 提供的文档是广泛的，应该查阅具体细节，但本文提供了对基本和更高级的相关功能的有用概述，传达了 npm 的强大之处。

与所有事物一样，存在强烈的意见，并且可以发现许多错误。 但是，如果您从未尝试过 npm（或 node，就此而言），请潜入并自己探索它。 您可能会比您想象的更享受它。

有关 npm 的更多有趣文章，请考虑阅读 Using Scala.js with npm and Browserify。