npm是如何处理依赖关系的

简介: npm是如何处理依赖关系的

首先我们在仓库 test 中 npm init 一个 package.json,然后 npm install react@16.13.1,此时 . node_modules 的目录结构如下:

test
    node_modules
      |    prop-types@15.6.2
    |    react@16.13.1

我们再安装一下 prop-types@15.5.0,此时的依赖图如下:

test
    node_modules
    |    prop-types@15.5.0
    |    react@16.13.1
            node_modules
            |    prop-types@15.6.2

我们会发现

1、由于 npm 会扁平化的安装依赖,所以 prop-types@15.5.0 会安装到顶级 node_modules中。

2、由于顶级 node_modules 已经有了 prop-types@15.5.0,所以 react 内部所依赖的 prop-types@15.6.2 会安装在 react 内部的 node_modules 中。

假如我们再安装一个 react-xxx@3.1.0,他依赖于 prop-types@15.5.0 和 react@16.12.0,所以,此时的 node_modules 结构图如下:

test
    node_modules
    |    prop-types@15.5.0
    |    react@16.13.1
            node_modules
            |    prop-types@15.6.2
  |    react-xxx@3.1.0
            node_modules
            |    react@16.12.0

我们发现

1、npm 在安装依赖时,首先在顶级 node_modules 下安装了 react-xxx@3.1.0
由于 prop-types@15.5.0 和顶级 node_modules下 的 prop-types 版本相同,所以不再单独安装。
2、由于 react 和顶级 node_modules 下的 react 版本不一致,所以在自己 node_modules 内部单独安装 react@16.12.0。

如果有其他安装包,以此类推。。。。

注意,在 package.json 中指定一个特定版本依赖是不够的,因为你希望确保最终用户获得完全相同的依赖关系树,包括其所有子依赖关系。而 package.json 中的一个特定版本保证只会发生在顶层。

在 package.json 文件只能锁定大版本,也就是版本号的第一位,并不能锁定后面的小版本,你每次 npm install 都是拉取的该大版本下的最新的版本,为了稳定性考虑我们几乎是不敢随意升级依赖包的,这将导致多出来很多工作量,测试/适配等,所以 package-lock.json 文件出来了,当你每次安装一个依赖的时候就锁定在你安装的这个版本。

注意,当需要移除 package-lock 再生成一份的时候,或者直接执行 npm install,如果 npm 包发布了新的版本,这个时候 package-lock.json 就会发生改变,安装的依赖就自动被升级了。

相关文章
|
6月前
|
JavaScript Linux 数据安全/隐私保护
node内网安装npm私服以及依赖包上传发布verdaccio
node内网安装npm私服以及依赖包上传发布verdaccio
448 1
|
6月前
|
缓存 资源调度
解决安装依赖时报错:npm ERR! code ERESOLVE
解决安装依赖时报错:npm ERR! code ERESOLVE
3099 0
解决安装依赖时报错:npm ERR! code ERESOLVE
|
3月前
|
缓存 资源调度 持续交付
在清空NPM缓存后,检查是否所有依赖都已正确安装
在清空NPM缓存后,检查是否所有依赖都已正确安装
|
1月前
|
缓存 资源调度 持续交付
在清空NPM缓存后,我如何检查是否所有依赖都已正确安装?
【10月更文挑战第5天】在清空NPM缓存后,我如何检查是否所有依赖都已正确安装?
|
24天前
|
缓存 前端开发 JavaScript
前端架构思考:代码复用带来的隐形耦合,可能让大模型造轮子是更好的选择-从 CDN 依赖包被删导致个站打不开到数年前因11 行代码导致上千项目崩溃谈谈npm黑洞 - 统计下你的项目有多少个依赖吧!
最近,我的个人网站因免费CDN上的Vue.js包路径变更导致无法访问,引发了我对前端依赖管理的深刻反思。文章探讨了NPM依赖陷阱、开源库所有权与维护压力、NPM生态问题,并提出减少不必要的依赖、重视模块设计等建议,以提升前端项目的稳定性和可控性。通过“left_pad”事件及个人经历,强调了依赖管理的重要性和让大模型代替人造轮子的潜在收益
|
3月前
|
缓存 资源调度 持续交付
在清空NPM缓存后,如何检查是否所有依赖都已正确安装
在清空NPM缓存后,如何检查是否所有依赖都已正确安装
|
4月前
|
运维 Kubernetes Java
阿里云云效操作报错合集之npm包已经发布到了制品仓库,但流水线中拉取依赖时出现404错误,该如何排查
本合集将整理呈现用户在使用过程中遇到的报错及其对应的解决办法,包括但不限于账户权限设置错误、项目配置不正确、代码提交冲突、构建任务执行失败、测试环境异常、需求流转阻塞等问题。阿里云云效是一站式企业级研发协同和DevOps平台,为企业提供从需求规划、开发、测试、发布到运维、运营的全流程端到端服务和工具支撑,致力于提升企业的研发效能和创新能力。
阿里云云效操作报错合集之npm包已经发布到了制品仓库,但流水线中拉取依赖时出现404错误,该如何排查
|
3月前
|
存储 安全 Java
阿里云云效产品使用合集之怎么设置使用npm私有仓库进行流水线拉取依赖
云效作为一款全面覆盖研发全生命周期管理的云端效能平台,致力于帮助企业实现高效协同、敏捷研发和持续交付。本合集收集整理了用户在使用云效过程中遇到的常见问题,问题涉及项目创建与管理、需求规划与迭代、代码托管与版本控制、自动化测试、持续集成与发布等方面。
|
4月前
npm-check【实用教程】升级项目中的依赖
npm-check【实用教程】升级项目中的依赖
71 0
|
4月前
包管理工具——npm实用教程 (修改下载源,安装依赖 -D -S -g ,卸载依赖等)
包管理工具——npm实用教程 (修改下载源,安装依赖 -D -S -g ,卸载依赖等)
68 0