您好,登录后才能下订单哦!
今天小编给大家分享的是NPM机制的详细介绍,相信很多人都不太了解,为了让大家更加了解NPM机制,所以给大家总结了以下内容,话不多说,一起往下看吧。
使用NPM安装的时候会经常出现包冲突(比如多个主模块的子模块版本不一致等),导致在开发过程中会遇到各种或大或小的问题。所有在这会介绍以下内容:
NPM 各种安装方式
npm install packageName[@next | @versionNumber]
npm install packageName --f | -- force
npm update packageName
NPM 查询服务
npm view packageName [version]
查询对映模块的信息输入 npm install 命令并敲下回车后,会经历如下几个阶段(以 npm 5.5.1 为例):
1. 执行工程自身 preinstall
当前 npm 工程如果定义了 preinstall 钩子此时会被执行。
2. 确定首层依赖模块
首先需要做的是确定工程中的首层依赖,也就是 dependencies
和 devDependencies
属性中直接指定的模块(假设此时没有添加 npm install 参数)。
工程本身是整棵依赖树的根节点,每个首层依赖模块都是根节点下面的一棵子树,npm 会开启多进程从每个首层依赖模块开始逐步寻找更深层级的节点。
如果查询node_modules目录之中已经存在指定模块,那么不再重新安装
3. 获取模块
获取模块是一个递归的过程,分为以下几步:
获取模块信息
获取模块实体。
查找该模块依赖
4. 模块扁平化(dedupe)
一步获取到的是一棵完整的依赖树,其中可能包含大量重复模块。比如 A 模块依赖于 loadsh,B 模块同样依赖于 lodash。在 npm3 以前会严格按照依赖树的结构进行安装,因此会造成模块冗余。
从 npm3 版本
开始默认加入了一个 dedupe 的过程。它会遍历所有节点,逐个将模块放在根节点下面,也就是 node-modules 的第一层。当发现有重复模块时,则将其丢弃。
这里需要对重复模块进行一个定义,它指的是模块名相同且 semver 兼容。每个 semver 都对应一段版本允许范围,如果两个模块的版本允许范围存在交集,那么就可以得到一个兼容版本,而不必版本号完全一致,这可以使更多冗余模块在 dedupe 过程中被去掉。
比如
举个例子,假设一个依赖树原本是这样:
node_modules
-- foo
---- lodash@version1
-- bar
---- lodash@version2
假设 version1 和 version2 是兼容版本,则经过 dedupe 会成为下面的形式:
node_modules
-- foo
-- bar
-- lodash(保留的版本为兼容版本)
假设 version1 和 version2 为非兼容版本,则后面的版本保留在依赖树中:
node_modules
-- foo
-- lodash@version1
-- bar
---- lodash@version2
5. 安装模块
这一步将会更新工程中的 node_modules,并执行模块中的生命周期函数(按照 preinstall、install、postinstall 的顺序)。
6. 执行工程自身生命周期
当前 npm 工程如果定义了钩子此时会被执行(按照 install、postinstall、prepublish、prepare 的顺序)。
最后一步是生成或更新版本描述文件,npm install 过程完成。
关于NPM机制的详解就分享到这里了,希望以上内容可以对大家有一定的参考价值,可以学以致用。如果喜欢本篇文章,不妨把它分享出去让更多的人看到。
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。