npm指南（Node.js程序包管理器） _依赖管理

本文概述

CLI命令
ASL-配置
使用npm更新npm
开发自己的npm软件包
ASL组织
npm的力量

在开发网站和Web应用程序时, JavaScript无疑是最常用的语言。众多资源令人震惊, 可用库的数量更是如此。
最初, 这些库很少且易于维护。但是, 很快就会出现足够多的依赖关系, 因此需要更成熟的解决方案。

文章图片
输入Node Package Manager(npm)-一个最常与Node.js结合使用的JavaScript软件包管理器, 尽管它也可以独立使用。它使你可以对项目的依存关系进行出色的控制, 并提供了一种为开源世界做贡献的好方法。
你可以通过简单地运行npm install < package name> 并将其注入JavaScript文件来开始使用。
是否要安装特定版本？没问题。运行npm install < 软件包名称> @ 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 markdown获得搜索结果列表。
这里是突出的核心命令。

安装：这里提到它是因为在使用npm时绝对必要。用于在本地或全局安装新软件包(添加-g时), 或安装package.json文件中列出的依赖项(稍后会详细介绍)。
卸载：这也是必不可少的。它用于从node_modules目录中本地或全局(添加-g时)清除特定程序包。
访问：这是npm-organizations和范围(专用)包中的npm用户权限管理员的场所。严重强大的东西。与adduser, 所有者, 团队等结合使用, 它可以对谁有权访问哪些内容进行精细控制。
斌：到底在哪里安装软件包？运行此命令以查看绝对文件路径。
缓存：如果你从npm的左, 右和中心开始安装软件包, 此命令将非常有用。可以使用ls子命令调用它以查看本地缓存的软件包的列表, 也可以使用clean子命令来清除缓存中的所有软件包。当npm注册表仍然有点不稳定时, 这对于返回稳定的环境或在你未正确设置npm权限时重置某些内容非常重要。
config：稍后我们将介绍不同的配置选项, 但是此命令主要通过使用set, get或delete子命令处理将配置属性持久存储在本地或全局配置文件中的问题。
重复数据删除或ddp：在很长时间内处理项目并直接从npm安装软件包时, 此命令将遍历本地软件包树并尝试简化依赖关系。
链接：开发自己的npm软件包时, 这使你可以创建到全局上下文的符号链接, 以便可以像从npm注册表中全局安装它一样对其进行测试。例如, 如果要在全局安装了CLI的节点上编写组装工具, 则可以运行此命令并测试CLI的行为, 而无需先部署它。
ls：用于以树状结构可视化软件包的依存关系及其依存关系。看起来很酷, 并且对于与其他项目进行比较也很有用。
已过期：用于评估已安装依赖项的当前状态以及它们是否已过期。在根依赖项列表长数百行的项目中, 几乎不可能手动检查软件包。在此命令中添加-g – depth = 0可以使你还检查全局安装的软件包。
发布：为npm开发自己的软件包时, 此命令必不可少。确实如其名称所示。它将你的软件包发布到npm注册表。
搜索：使用此命令在注册表中搜索所有包含第三个参数中提供的文本的软件包。
收缩包装：简而言之, 该命令使你可以按顺序锁定软件包中的特定依赖项版本, 以便宽松的semver(语义版本控制)编号不会破坏生产代码。
star：你真的喜欢你使用的包裹吗？使用此命令可以直接在终端上显示你的赞赏, 然后在npm注册表中的软件包页面上反映出来。
更新：这通常在过时的命令之后更新任何过时的软件包。
版本：这为你提供了一个简化package.json版本属性的快捷方式, 并且可以一次完成git标签。

请注意, 这些命令中的大多数都可以采用子命令和/或配置, 并且此列表绝不是关于CLI的最终讨论。
ASL-配置配置是npm的主要部分, 可以通过多种方式设置配置变量。
通过CLI和环境变量进行配置
首先, 可以从终端通过CLI设置配置。
通常情况如下：npm < 命令> -< 配置选项> [< 可选值> ]。
如果未指定该值, 则默认情况下该选项将设置为true。
例如, 假设你正在处理一个有范围的(私有)npm程序包, 然后决定将其发布为公共程序包。
通过将– access = public附加到你的发布命令即可轻松完成此操作。如果我们未将属性指定为公共属性, 则默认值为受限(私有)。
诸如此类的附加到其他命令的配置不会在所有地方持久存在, 因此通过CLI设置一系列配置可能会很麻烦。
在这些情况下, 最好使用环境变量来设置配置。
带有npm_config_前缀的任何环境变量都将用于配置npm。
例如：export npm_config_registry = localhost：4321将全局设置注册表配置选项, 并且在执行npm时, 它将使用位于端口4321上localhost的npm注册表。
通过npmrc文件进行配置你还可以使用特殊的.npmrc文件来设置配置选项, 该文件可以根据你的要求设置为不同级别：

项目级别：位于项目代码的根目录以及package.json文件, 通常为path / to / project / .npmrc
用户级别：配置特定用户帐户的目录, 通常为?/ .npmrc
全局级别：npm查找全局配置的目录, 通常为$ PREFIX / etc / npmrc
内置级别：谨慎。此配置不仅是全局的, 而且是npm源代码的一部分, 并且最佳实践建议(实际上是要求)我们不要更改我们不负责维护的代码。通常可以在/ path / to / npm / npmrc中找到它。

通过使用以下格式的命令, 可以使用CLI修改并保留.npmrc文件中的配置设置：npm config set < key> < value> 。
例如, 你可以运行npm config set access public以使作用域(专用)程序包的发布配置永久公开。
默认情况下, 此命令将在本地持久化配置(如上所述的用户级别配置), 但是你可以添加-g以在全局范围内持久化它。
当需要在项目级别或内置级别上进行持久配置时, 必须使用文本编辑器修改.npmrc文件。
通过package.json配置最后, 可以从package.json文件设置配置。但是, 这很少使用(并且仅在明确需要时才使用), 因为按惯例, 项目级别的.npmrc文件是设置软件包配置的首选位置。
值得注意的配置设置

访问：如上所述, 它用于设置权限。
always-auth：请务必注意, 此设置默认为false。设置为true时, npm在联系注册表时将始终要求身份验证。
ca：默认为npm证书颁发机构(CA)。可以将其更改为null以仅允许访问已知的注册商, 或将其更改为特定的CA证书仅授予对该特定证书的访问权限。很少使用此设置以及cafile, cert和strict-ssl, 但是谈到npm的安全性和可靠性方面时, 可以放心地知道所安装的软件包来自你期望的源。
color：默认为true, 通过为tty文件描述符允许的stdout着色, 使你摆脱终端的标准缺陷。如果设置为false, 则终端将保持沉闷状态。设置为始终时, 始终以彩色输出。
深度：此设置可通过指定执行的深度, 对递归命令(例如lsand过时)进行细化控制。值为0只会评估第一级依赖关系, 而无穷大(默认值)将导致评估所有等级的依赖关系。该规则的例外是在过时使用时；在这种情况下, 将无穷大解释为0以确保获得更多相关输出。
dev：默认情况下将其设置为false, 但是当将其设置为true时(进行npm安装时), package.json文件中的所有开发依赖项将与常规依赖项一起安装。
空运行：将此设置设置为true时, npm不会对程序包进行任何更改, 而是会告诉你它会做什么。这在运行某些命令(例如重复数据删除或更新)时非常有用。
git-tag-version：默认情况下设置为true。运行npm version命令时, 此设置在git中标记版本。如果你将npm用作大型项目的软件包管理器, 该项目在git中标记了版本, 则可以节省时间, 并记住为你更新package.json文件。
loglevel：默认情况下, 它设置为warn, 在运行npm命令时会给出错误和警告输出。其他设置包括无声, 不提供任何输出。错误, 仅将错误记录到输出中； http, 仅宣布http请求错误；信息, 以获取有用的信息)；详细, 几乎记录了所有内容；愚蠢的, 顾名思义, 愚蠢地提供了一些输出。
生产：将其设置为true时, npm会相应动作并以生产模式运行所有命令。这意味着将不会安装开发或可选依赖项, 也不会执行任何与开发相关的任务。
回滚：设置为true时, 将删除所有失败的安装。当依赖项安装失败时, 这会派上用场。根据你的日志记录级别, 你应该能够查看哪些安装失败, 记下这些安装, 并在rollback选项设置为true的情况下运行npm install命令。然后使用注释和空运行安装(如上所述), 然后可以调试问题。
保存：直接从注册表中安装软件包时, 可以在命令后面附加–save, 该命令会将已安装的软件包添加到package.json文件中的dependencies选项中。例如, npm install lodash`会将lodash添加到你的依赖项中。
save-dev：类似于save配置选项, 在安装软件包时添加– save-dev, 然后它将被添加到package.json文件中的devDependencies选项。
save-optional：类似于保存配置选项, 在安装软件包时添加– save-optional, 然后它将被添加到package.json文件中的optionalDependencies选项中。
save-exact：安装软件包时, save, save-dev和save-optional选项通过使用semver range运算符将已安装的软件包插入其各自的属性中来修改package.json文件。当调用值为true的” 保存精确” 配置设置时, 结合上述设置之一, 将使用特定的版本号, 而忽略存储范围。
save-prefix：在使用save, save-dev或save-optional时, 设置semver范围运算符。默认值为^, 允许在安装时对软件包进行较小的升级。可以将其设置为任何有效的前缀semver范围运算符。
tag-version-prefix：常规默认值为v, 指定运行npm version时git标签版本的前缀。

使用npm更新npm 你也可以使用npm进行自我更新。
只需运行npm install -g [受电子邮件保护], npm将更新为最新的稳定版本。重要的是要注意, 每个版本的Node.js都带有特定的npm版本, 以我的经验, 你应该不要过多地使用该配对。
归根结底, 我的建议是按预期坚持配对。
将npm用作独立工具时, 请确保你了解使用所选版本的含义。有一个很棒的工具可以在称为nvm的同一系统上管理不同的Node.js版本(进而是npm版本)。
package.json文件
package.json文件是将所有内容链接在一起的关键元素。
这是将程序包发布到npm注册表的要求, 并且依赖项的管理部分也应运而生。
它具有两个必填字段, 即” 名称” 和” 版本” , 并且这些属性一起应该是唯一的标识符。
名称字段应遵循npm命名文档中定义的某些规则, 而版本字段则受制于特定的规范。

文章图片
除此之外, 你还可以拥有一英里长的依赖项列表, 并使用semver版本和range运算符定义要用于每个依赖项的特定版本。以下是其他值得注意的属性列表。
“ 主要” ” main” 定义了应用程序的入口点, 默认为index.js。根据约定或你的框架, 它可能是app.js或main.js。当然, 你可以随心所欲。
“ 脚本” 这是被低估的财产。
首先, 它可以用于在预发布时执行操作。
其次, 它提供了一个位置, 你可以在其中放置一系列常用命令的别名, 这些命令范围包括构建任务(以gulp或grunt定义), 触发其他依赖项的安装(带有Bower), 使用webpack启动开发服务器或运行一组bash命令。
“ 依赖关系” 此属性是你的应用程序所需的软件包的列表, 以及兼容的存储库编号。这是一个值得注意的属性, 因为在安装本地软件包时可以在终端上对其进行修改。
这是通过在npm install命令末尾添加– save(或简写-S)来完成的。
执行此操作时, 新安装的软件包将添加到package.json文件中的依赖项列表中。
同样, 在运行npm uninstall命令时, 也可以通过添加– save删除依赖项。
重要的是要知道每个依赖项的semver版本控制模式及其含义。
如果semver规则过于严格, 则会失去新功能和改进, 而如果semver规则过于宽松, 则可以沿线安装软件包的破坏版本。
破损的软件包安装可能非常难解决, 尤其是在使用压缩版的软件包时。
” devDependencies” 与依赖关系属性分开, ” devDependencies” 属性使你可以定义仅在开发阶段使用且生产构建不需要的依赖项(例如ESLint, grunt-contrib包和Protractor)。与依赖项一样, 可以在终端上通过在npm install命令或npm install命令的末尾添加– 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> , 其中up??date_type是semver所述的patch, minor或major, 然后自动增加package.json文件中的版本号。
ASL组织再次, npm文档对此非常有用, 重复他们的话是徒劳的。
在npm上下文中, 可以说的是组织的细粒度, 如果管理得当, 可以很好地管理和限制大型团队和个人, 以一个名称处理范围内或公共程序包。
虽然掌握起来很复杂, 但却是非常有益的。
npm的力量最终, npm提供的文档是广泛的, 应咨询具体细节, 但是本文提供了基本功能和更高级的所涉及功能的有用概述, 传达了npm的精妙之处。
与所有事物一样, 存在强烈的意见并且可以发现许多错误。但是, 如果你从未尝试过npm(或者说是节点), 那么请亲自研究一下。你可能会比想象中的更喜欢它。
【npm指南（Node.js程序包管理器）】有关npm的更多有趣文章, 请考虑阅读结合使用Scala.js和npm和Browserify。