一.NPM简介
1.npm是什么
npm (node package manager)是 JavaScript 世界的包管理工具,并且是 node.js 平台的默认包管理工具。 通过 npm 可以 安装、共享、分发代码,管理项目依赖关系。
(npm(“Node 包管理器”)是 JavaScript 运行时 Node.js 的默认程序包管理器。)。也是世界上最大的软件注册表,每星期大约有 30 亿次的下载量,里面包含超过600000个包(代码模块)的结构,来自各大洲的开源软件开发者使用npm互相分享和借鉴,能够使您轻松跟踪依赖项和版本。
2.npm的组成
(由三个独立的部分“网站、注册表、命令行工具”组成)
网站 :是开发者查找包、设置参数以及管理 npm 使用体验的主要途径
注册表(registry):是一个巨大的数据库,保存了每个包(package)的信息。
命令行工具 (CLI):通过命令行或终端运行。开发者通过 CLI 与 npm 打交道
为了更直观地解释,我们可以将数据库 npmjs.com 视为一个物流集散中心,该中心从卖方(npm 包裹的作者)那里接收货物的包裹,并将这些货物分发给买方(npm 包裹的用户)。
为了促进此过程,npmjs.com 物流集散中心雇用了一群勤劳的袋熊(npm CLI),他们将被分配给每个 npmjs.com 用户作为私人助理。 因此,“dependencies(依赖项)(npm包裹)”会如下传递给 JavaScript 开发人员:
发布 JS 软件包的过程如下:
3.npm的用处
将软件包调整到应用程序中,或按原样合并它们
下载可立即使用的独立工具
无需使用npx下载即可运行包
与任何npm用户共享代码
将代码限制为特定开发人员
组建虚拟团队
管理多个版本的代码和代码依赖项
更新基础代码时,轻松更新应用程序
发现解决同一难题的多种方法
4.package.json
每个 JavaScript 项目(无论是 Node.js 还是浏览器应用程序)都可以被当作 npm 软件包,并且通过 package.json 来描述项目和软件包信息。
我们可以将 package.json 视为快递盒子上的运输信息。
当运行 npm init 初始化 JavaScript/Node.js 项目时,将生成 package.json 文件,文件内的内容(基本元数据)由开发人员提供:
✸name: JavaScript 项目或库的名称。
✸version: 项目的版本。通常,在应用程序开发中,由于没有必要对开源库进行版本控制,因此经常忽略这一块。但是,仍可以用它来定义版本。
✸description: 项目的描述。
✸license: 项目的许可证。
5.package-lock.json
该文件描述了 npm JavaScript 项目中使用的“依赖项(npm包裹)”的确切版本。(如果 package.json 是通用的描述性标签,则 package-lock.json 是成分表。)
就像我们通常不会读取食品包装袋上的成分表(除非你太无聊或需要知道)一样,package-lock.json 并不会被开发人员一行一行进行读取。
package-lock.json 通常是由 npm install 命令生成 的,也可以**由我们的 NPM CLI 工具读取**,以确保使用 npm ci 复制项目的构建环境。
二.用户如何使用 NPM
npm 已帮助发布了 130 万个软件包,每周下载量超过 160 亿次! 这些数字对于任何软件工具来说都非常厉害。由此可以推断出,大多数 npm 用户都朝这个方向使用 npm。所以,了解如何使用这个强大的工具会很有帮助。
NPM中可以只运行一个命令来 安装多个模块、获取包的信息、安装特定版本的软件包、列出依赖项 等等有用的提示和技巧
1.npm install
这是现在我们开发 JavaScript/Node.js 应用程序时最常用的命令。
默认情况下,npm install 将安装带有 ^ 版本号的软件包的最新版本。npm 项目上下文中的 npm install 将根据package.json规范将软件包下载到项目的 node_modules 文件夹中,从而升级软件包的版本(并重新生成package-lock.json )。 npm install 可以基于 ^ 和 〜 版本匹配。
如果要在全局上下文中安装程序包,可以在机器的任何地方使用它,则可以指定全局标志 -g (例如 live-server)。
使安装 JavaScript 软件包非常容易,以至于经常错误地使用此命令。
包太大、太深这样的问题可以通过 --production 标志来拯救!在上一节中,(分别用于生产和开发/测试环境的 dependencies 和 devDependencies ) 。 这个 --production 标志是如何在 node_modules 中进行区别的。
通过将此标志附加到 npm install 命令,我们将仅从 dependencies 安装软件包,从而将 node_modules 的大小大大减小到应用程序正常运行所必需的大小。——不应该将 devDependencies 引入生产环境!
2.npm ci
如果 npm install --production 对于生产环境是最佳选项,那么是否必须有一个对本地环境,测试环境最合适的选项?
答案是 npm ci 。
就像如果 package_lock.json 尚不存在于项目中一样,无论何时调用 npm install 都会生成它, npm ci 会消耗该文件( package_lock.json ),来下载项目所依赖的每个软件包的确切版本。
这样,无论是用于本地开发的笔记本电脑还是 Github Actions 等 CI(持续集成)构建环境,我们都可以确保项目上下文在不同机器上保持完全相同。
3.npm audit
随着越来越多的软件包发布,并且易于安装,因此 npm 软件包容易受到恶意作者的恶意攻击,例如这些。
意识到生态系统存在问题,npm.js 组织提出了 npm audit 的主意。 他们维护了一个安全漏洞列表,开发人员可以使用 npm audit 命令来审核项目中的依赖项。
npm audit 为开发人员提供了有关漏洞以及是否有要修复的版本的信息,例如:
如果补救措施在下一个不间断的版本升级中可用,则可以使用 npm audit fix 来自动升级受影响的依赖项的版本。
三.作者如何使用 NPM
将软件包发送到 npmjs.com (地址可改) 非常容易,因为我们只需要运行 npm publish 。
棘手的部分(并非专门针对 npm 软件包作者)是确定软件包的版本。
根据 semver.org 的经验法则:
1.当你进行不兼容的 API 更改时使用 MAJOR 版本
2.以向后兼容的方式添加功能时使用 MINOR 版本
3.进行向后兼容的 bug 修复时使用 PATCH 版本
发布软件包时,遵循上述规则尤为重要,可以确保你不会破坏任何人的代码,因为 npm 中匹配的默认版本是^(又称下一个次版本)。
四.具体应用
1.生成 package.json
我们通常执行 npm init,然后开始添加 npm 请求的信息。
但是,如果我们不关心所有这些信息,并且希望保留默认值,那么对于 npm 请求的每一条数据,我们都按 enter 键。为了避免这种情况,你可以输入 npm init -y。这样就可以跳过问题询问了。
注:你也可以使用 npm init --yes 作用是一样的。
2.安装模块
你可以使用更加简单的npm i 来代替 npm install;
3.一次安装多个模块
你不需要为每个模块键入一个 npm install 命令,例如:
bash 代码: npm i gulp-pugnpm i gulp-debugnpm i gulp-sass
你可以只运行一个命令,一次性安装所有这些模块:
bash 代码: npm i gulp-pug gulp-debug gulp-sass
还有更加简单的方法,如果所有名称都以相同前缀开头,你不需要键入整个名称:
bash 代码: npm i gulp{-debug,-sass,-pug}
4.使用 install flags(安装参数) 的快捷方式
如果要安装软件包并将其另存为生产依赖项,则通常会这样做
bash 代码: npm i gulp --save-prod
你可以使用 -P 快捷方式,像这样:
bash 代码: npm i gulp -P
对于开发依赖项也是一样,不需要键入完整的 --save-dev 标志,你可以使用 -D 快捷方式,像这样:
bash 代码: npm i gulp -D
默认情况下,当你运行不带任何 flags(参数) 的 npm install 时,npm 会将包作为依赖项添加到 package.json 文件中。 如果要防止这种情况,请使用 --no-save flags(参数) 安装,如下所示:
bash 代码: npm i gulp --no-save
5.获取包信息
下面的命令将显示 vue 包 的相关信息:
npm view vue 或 npm v vue
如果你只想获得最新版本的软件包,可以试试下面这个命令:
bash 代码: > npm v vue version> 2.5.17
如果你想获得 npm 包完整的版本列表,请尝试复数形式
bash 代码: > npm v vue versions>
[ ‘0.0.0’, ‘0.6.0’, ‘0.7.0’, … ‘2.5.15’, ‘2.5.16’, ‘2.5.17-beta.0’, ‘2.5.17’ ]
6.安装特定版本的软件包
如果要安装版本,而不是最新版本的软件包,可以键入:
bash 代码: npm i vue@2.5.15
鉴于记忆名称比数字更容易(至少对我来说),你可以使用 dist-tag 列表中名称,运行 npm v 命令即可得到该列表 ,如下所示:
bash 代码: npm i vue@beta
7.搜索 package(包)
有时你可能记不住你前一段时间或你朋友推荐的某个 package(包) 的确切名称。 在这种情况下,你可以使用 npm 搜索,直接在终端中执行搜索:
bash 代码: npm search gulp debug
或者
bash 代码: npm s gulp debug
8.卸载 package(包)
如果你不想打开 package.json 文件并从那里手动删除依赖项,则可以使用以下命令将其删除:删除vue包
bash 代码: npm uninstall vue
这将从 node_modules 文件夹和 package.json 文件中删除该包。 当然,你可以使用 rm , un 或 r 来实现相同的效果,例如:
bash 代码: npm rm vue
如果由于某种原因你只想从 node_modules 文件夹中删除包文件,但仍然将其作为依赖项保存在 package.json 文件中,则可以使用 --no-save 参数:
bash 代码: npm rm vue --no-save
五.npm 全局安装与本地安装、开发依赖和生产依赖
先抛几个常见疑惑:
1.什么是全局安装、什么是本地安装(或叫局部安装,下文统一叫本地安装) ?
2.为什么要全局安装?为什么要本地安装?全局安装和本地安装有什么区别?
3.什么叫开发依赖、生产依赖?什么又是开发环境、生产环境?
全局安装与本地安装
一、全局安装:
npm install -g //(这里-g是-global的简写)
通过上面的命令行(带-g修饰符)安装某个包,就叫全局安装。通常全局包安装在node目录下的node_modules文件夹。可以通过执行下面几条命令查看node、npm的安装目录和全局包的安装目录。
1.which node // 查看node的安装目录
2.which npm // 查看npm的安装目录
3.npm root -g // 查看全局包的安装目录
4.npm list -g --depth 0 //查看全局安装过的包
二、本地安装:
npm install (后面可以加几种修饰符,主要有两种–save-dev和–save)
通过上面的命令行安装某个包,就叫本地安装。包安装在你当前项目文件夹下的node_modules文件夹中。
三、全局安装的作用:
全局安装的包可提供直接执行的命令(例:gulp -h可以查看gulp定义了什么命令)。 比如gulp全局安装后,可以在命令行上直接执行gulp -v、gulp -h等 (原理:全局安装的gulp会将其package.json中的bin命令注入到了全局环境,使得你可以全局执行:gulp xxx命令,这另一个话题了,不深入) 。倘若只在本地安装了gulp,未在全局安装gulp,直接执行这些命令会报错。你想要执行相应的命令则可能需要例如:node ./node_modules/gulp/bin/gulp.js -v(查看版本) 这样用一大串命令来执行。因此全局安装就发挥到他的好处了呀,一个gulp -v就搞定
当然,不是每个包都必须要全局安装的,一般在项目中需要用到该包定义的命令才需要全局安装。比如gulp 执行gulp任务…等,所以是否需要全局安装取决于我们如何使用这个包。全局安装的就像全局变量有点粗糙,但在某些情况下也是必要的,全局包很重要,但如果不需要,最好避免使用。
四、可以全局安装,那么直接全局安装到处使用就行了,干嘛还需要本地安装?
如果只是全局安装了而没本地安装,就得require(’’) 例:引入一个全局的包可能就是requirt(’/usr/local/…’)通过全局包的路径引入,这样显然十分的不灵活。如果安装了本地包,那么 就可以直接require(’’)引入使用。
一个包通常会在不同的项目上会重复用到,如果只全局安装,那么当某个项目需要该包更新版本时,更新后可能就会影响到其他同样引用该包的项目,
因此本地安装可以更灵活地在不同的项目使用不同版本的包,并避免全局包污染的问题。
一个经验法则:要用到该包的命令执行任务的就需要全局安装,要通过require引入使用的就需要本地安装( 但实际开发过程中,我们也不怎么需要考虑某个包是全局安装还是本地安装,因为这一点在该包的官网上一般会明确指出,以上是为了理解全局安装和本地安装)
开发依赖和生产依赖
顺着上面讲到的本地安装,本地安装有两种主要的安装方式:
保存到开发依赖(devDependencies):
npm install < pageName> --save-dev
等同 npm install < pageName>
保存到生产依赖(dependencies):
npm install < pageName> --save
"开发依赖"顾名思义在开发环境中用到的依赖,"生产依赖"在生产环境中用到的依赖。那么这里又延伸出个问题什么是开发环境、什么是生产环境?
一、开发环境和生产环境
【开发环境】:指的是你的项目尚且在编码阶段时的环境。你在代码可能还有各种console.log()、注释、格式化等。
【生产环境】:指的是你的项目已经完成编码,并发布上线可供用户浏览的阶段时的环境。代码可能经过了压缩、优化等处理。
这些概念其实并没有一个很明确的定义,接下来我们举例个场景,将"开发环境"、“生产环境"和上面的"开发依赖”、"生产依赖"联系起来就会比较容易理解的了。假如我们在开发过程中使用jQuery。在以往,可能就是把jQuery这个插件下载的本地,再通< script>引入html中。但这有个不方便的地方,我们每次进行一个项目的时候就得手动复制这个jQuery文件到我们的项目中,如果想要换个版本又得官网上下载、随着项目越来越多。用到的插件、库也随之越繁杂…这样会造成自家用的插件管理繁琐的问题。因此就出现了npm(包管理工具) 你需要用到什么,直接通过一条命令行就可以将想要的插件下载下来,并直接引入到项目中,目前几乎所有的js插件都能在npm上直接下载。
二、生产依赖 npm -i xxx --save–dev
回到环境和依赖话题,我们下载的jQuery,在开发时参与源码编写,在发布上线的生产环境中也是需要它的。不仅在开发环境编写代码时要依赖它、线上环境也要依赖它,因此将它归类为"生产依赖",安装时执行npm install jquery --save,它就会被记录在package.json的dependencies。当进行代码打包时,会将这里的jQuery打包入我们的项目代码中。
三、开发依赖 npm -i xxx --save
接着,假如我们用gulp对html进行压缩,我们通常会用到一个插件gulp-htmlmin。我们只希望它把html压缩完就ok了,并不希望它融入我们的项目代码中,即只存在于开发环境,因此把他归类为"开发依赖"。安装时执行npm install gulp-htmlmin --save-dev它就会被记录在package.json的devependencies下,当进行代码打包时,不会将这里的gulp-htmlmin插件源码打包入我们的项目代码中
devDependencies只会在开发环境下使用,生产环境不会被打入包内;而dependencies不仅在开发环境中要使用,生产环境也需要使用到。根据以上规则,我们就很容易区分哪些插件是用–save-dev模式安装,哪些用–save模式安装。