npm
直接进行依赖modules的嵌套 缺点:层级过深,依赖地狱,复用性不好,不确定性:不同的成员安装依赖可能是不一样的node_module。
升级: 将依赖统一的提升,解决了层级过深。 缺点:还是会有重复的依赖,幽灵依赖,依赖提升不确定性
yarn
yarn-lock文件:每个包的版本,顶层提升依赖的版本,锁定node_modules 解决了不确定性,并行下载加快下载速度。 缺点:不同项目间重复依赖,还是有幽灵依赖。同项目重复安装依赖
pnpm
软链接+硬链接 包被安装到store全局空间:通过.pnpm文件夹下的硬连接来指向存储的包(解决了重复依赖的问题),通过软连接来表示依赖关系,nodulemodules顶层只有显示声明的依赖,通过软连接指向(解决了幽灵依赖)
corepack
Corepack 是 Node.js 官方推出的工具,内置支持:从 Node.js 16.13.0 版本起内置(默认可能未启用,需手动开启),无需额外安装 Corepack 的核心作用之一就是确保同一个项目的所有开发者(以及 CI/CD 等环境)使用完全相同版本的包管理工具(如 npm、yarn 或 pnpm)。 具体来说,当项目的 package.json 中通过 packageManager 字段指定了具体版本(例如 "packageManager": "pnpm@8.6.12"),任何开发者在该项目中运行包管理命令(如 pnpm install
)时,Corepack 会自动检测并使用指定版本,无需手动安装或切换版本,从根源上避免因包管理工具版本差异导致的依赖安装、构建等问题。 原理: 提前在系统中安装「垫片脚本」,替代原生包管理器命令的执行入口; 当执行包管理命令时,垫片先读取项目配置(package.json 的 packageManager 字段); 根据配置自动下载 / 调用指定版本的包管理器,确保执行环境的一致性。
bun & deno
Bun 和 Deno 都是现代 JavaScript/TypeScript 运行时
- yarnV2+都不需要node_modules了
PnP 是依赖管理的一次重要革新,通过 "全局缓存 + 映射表 + 钩子拦截" 的方式,解决了传统 node_modules
的根本性问题(幽灵依赖、冗余、不确定性),同时大幅提升了安装性能。但其缺点主要集中在生态兼容性和开发习惯的适应上。
- 假设你需要调试一个第三方依赖包的 bug,你不想等待作者发布新版本。你会用哪些方法在本地进行调试和验证?(例如 npm/pnpm link,patch-package, overrides/resolutions 等)。
npm link / pnpm link:本地源码联动,先下载包到本地仓库,然后修改。2.patch打补丁npm install patch-package --save-dev 修改modules npx patch-package <包名> 3.直接修改4.overrides墙壁制定依赖版本,覆盖依赖树。
-
npx 是什么?它和直接全局安装(npm i -g)一个包有什么区别?请举出 2-3 个你日常工作中会使用 npx 的场景。 1.创建项目脚手架,执行特定版本工具查看差异
-
当多个依赖包依赖于同一个包的不同版本时,可能会产生依赖冲突。你如何诊断和解决这类问题?npm ls [package-name] 和 overrides/resolutions 在这里能扮演什么角色?
npm ls <包名>展示该包在整个依赖树中的所有版本及引用路径,帮助定位冲突来源。- 方法 1:升级依赖包到兼容版本 若冲突是因依赖包版本过旧,尝试升级依赖(如 npm update package-b),使其支持高版本的子依赖。 方法 2:使用 overrides(npm)/ resolutions(yarn)强制统一版本
- 请描述一下发布一个 npm 包到公共 registry 的完整流程,包括版本管理、tagging、以及发布前的准备工作。
packge.json中要有特定的字段,比如name(在npm中唯一),version(遵守规则:不兼容API变更,向后兼容,FIX) npm login npm publish