跳到主要内容

包管理器✅

什么是包管理器，Node.js 下用过哪些包管理器，有什么区别？​

答案
  • 包管理器(package manager)负责依赖解析与安装、锁定版本、脚本执行、发布与缓存, 常用包管理器包括 npm、yarn、pnpm
  • 不同包管理核心差异集中在存储模型、安装速度、node_modules结构、工作区/Monorepo能力、锁文件与兼容性
  • Node 支持了 Node Corepack
特性npmYarnpnpm
安装速度较慢（顺序安装）较快（并行安装）非常快（缓存+硬链接）
磁盘占用较高（重复依赖）较低（缓存机制）极低（内容寻址+硬链接）
node_modules扁平结构，可能冲突扁平结构，可能冲突严格嵌套+符号链接，避免冲突
锁文件package-lock.jsonyarn.lockpnpm-lock.yaml
工作区支持v7起支持内建内建
生态兼容性最广泛高，部分支持PnP良好，部分包不兼容
适用场景小型项目、快速入门中型项目、一致性大型项目、节省空间、CI/CD优化([Reddit][1], [DEV Community][2])

延伸阅读:

NPM 的架构是怎样的？​

答案

NPM 组成包括三块

  1. NPM 站点 系统用户管理，NPM 包搜索、管理的能力
  2. NPM CLI 命令行工具，开发这基于 NPM 包管理仓库中的依赖，控制发布等操作
  3. NPM Registry 存储和分发 NPM 包的中央仓库，提供 NPM 相关接口服务，底层使用 CouchDB
提示

NPM registry 提供了大量的 API ,可以参考 NPM Registry API 文档, 可以私有化部署 registry 比如 verdaccio 等用来支持内部私有包。

NPM 存在哪些配置，分别有什么功能?​

答案

npm 的配置覆盖类似 git, 参考 npmrc

  • 运行时配置，通过 --config 选项传入
  • 项目配置，在项目根目录 .npmrc 文件中
  • 用户配置，在用户主目录 $HOME/.npmrc 文件中，可以通过 --userconfig 或 $NPM_CONFIG_USERCONFIG 配置
  • 全局配置 在 $PREFIX/etc/npmrc; 或者通过 --globalconfig $NPM_CONFIG_GLOBALCONFIG
  • 内建配置，在 npm 源码中定义 /path/to/npm/npmrc

package.json 中有哪些常用配置?​

对 Node 的配置，详见 Node.js package.json field definitions 包含

  • main 配置包名
  • main 配置入口
  • type 配置类型，module 采用 ESM 处理包， 或 commonjs 采用 commonjs 规范处理包
  • exports 配置包的导出
  • imports 支持导入策略配置

NPM 配置详见 package.json

  • version 包的版本，遵循 语义化版本 2.0.0 规范，内部使用 node-semver 比较版本
  • *dependencies 各种依赖，具体用例可以参考 dependencies 说明
    • dependencies 用于声明项目在生产环境中运行所必需的依赖项。安装 npm 包时会自动安装
    • devDependencies 用于声明仅在开发过程中需要的依赖项。安装 npm 包时不会安装，安装包时携带 -D, --save-dev
    • peerDependencies 用于声明当前包所依赖的其他包，但这些依赖项不会被自动安装。例如组件库等依赖 Vue 或 React 框架，而这些框架在业务代码里会安装。安装时携带 --save-peer
    • optionalDependencies 用于声明可选依赖项，这些依赖项不是项目正常运行所必需的。如果安装失败，npm 不会报错。安装时携带 -O, --save-optional
    • bundledDependencies 用于声明在发布包时需要打包的依赖项。 安装时携带 -B, --save-bundle
  • scripts 定义了可以在命令行中运行的脚本命令，通知内置了一系列钩子 用来处理包从安装，构建，测试，发布各环节的触发逻辑，同时可以通过自定义 pre/post 钩子组合复杂的脚来编排控制逻辑
  • bin 用于指定包的可执行文件, 命令行开发依赖这个选项
  • engines 用来指定包的运行环境，通常是 Node.js、NPM 版本等

什么是 monorepo 工程有哪些工具架构， 该如何选型 ？​

答案
  • Monorepo 是用一个仓库管理多包/多应用的工程范式，目标是依赖一致、联动开发、统一构建测试与发布。
  • 工具有分层：包管理与工作区(npm/pnpm/Yarn)→任务编排与拓扑执行(pnpm -r、npm -ws、Yarn workspaces)→增量/缓存与远程缓存(Nx/Turborepo)→版本发布与变更集(Lerna/Changesets/Rush)。
  • 关键能力：工作区本地联结(workspace: 协议)、拓扑排序执行、受影响范围推导(affected)、任务缓存(本地/远程)、发布自动化。
  • 选型要点：小中型优先 pnpm(workspaces+递归命令+快/省)；需要高阶缓存/受影响计算选 Nx/Turborepo；严格合规与大企业流程可选 Rush；版本发布用 Changesets/Lerna。
工具工作区任务编排缓存/受影响发布/策略适用
npm workspaces是npm -ws否否入门/兼容优先
pnpm是pnpm -r/filters本地硬链接，否受影响否性能/空间优先
yarn是(PnP 可选)workspaces本地缓存否零安装/PnP
Nx依赖包管理自选graph/target本地+远程缓存/affected可接入 Changesets大型前端/全栈
Turborepo依赖包管理自选pipeline本地+远程缓存/partial可接入 Changesets前端为主
Rush可配heft/自定义增量+策略内置发布策略规制/大型组织

示例说明: 最小演示拓扑排序与“受影响包”推导，模拟 CI 只构建受影响集（Nx/Turbo 的核心思想）。

延伸阅读:

npm workspaces 是什么概念， 主要是解决什么问题​

答案
  • npm workspaces（npm>=7）用于在单一仓库管理多包（Monorepo）：统一安装、联动开发、脚本编排与版本一致性。
  • 关键能力：本地联结（workspace: 协议）、一次安装复用缓存、跨包脚本一键运行, 利用 -w 过滤不同包
  • 解决问题：多包依赖耦合难、重复安装慢、跨包调试/发布繁琐、锁文件不一致、CLI 需进入子包逐个操作。

延伸阅读:

幽灵依赖是什么？​

答案

核心概念:

  • 幽灵依赖（Phantom/Ghost Dependency）：代码可 require/import 到某包，但该包未在当前包的 package.json 中声明依赖。
  • 成因：npm/yarn 的扁平/提升安装（hoist/flat node_modules）使上层或兄弟依赖“看起来可用”，掩盖声明缺失。
  • 风险：不可复现（换机/CI 失败）、版本漂移、隐式耦合与安全审计缺口。与“未使用依赖”（installed but unused）不同概念。
  • 解决：采用 eslint-plugin-import 插件，开启 no-extraneous-dependencies 规则，确保显式声明所有依赖。通过 CI 检查和自动化工具（如 depcheck）发现并修复幽灵依赖。

延伸阅读:

npm 有哪些常用命令？​

答案

核心概念:

  • npm 常用命令分为安装管理、脚本执行、发布与版本、信息与缓存、安全与审计、工作区六类。
  • 可复现安装用 npm ci；开发期安装依赖用 npm i/-D/-O；脚本统一用 npm run；一次性执行 CLI 用 npm exec/npx。
  • 发布链路包含 npm version/pack/publish；调试联调用 npm link；工作区用 -w/-ws 管理多包。
  • 安全基线：npm audit/fix 与锁文件配合；必要时 --ignore-scripts 降低脚本执行风险。
命令用途常用选项/说明
npm install (i)安装依赖--save-dev(-D)、--save-optional(-O)、--save-peer、--production
npm ci按锁文件严格安装CI 环境首选；不改写 lock
npm update / npm outdated升级/查看可升级遵循 semver；结合 npm-check-updates
npm run <script>执行脚本--silent、--if-present；自动解析 .bin
npm exec / npx一次性执行包的 CLI--no 仅本地；-y 允许临时安装；-p 指定包
npm init初始化项目npm init -y 快速生成
npm version / publish / pack版本、发布、打包version 触发 git tag；pack 预览包内容
npm link / unlink本地包联调全局链接到项目，调试本地包
npm config / cache配置与缓存config get/set registry；cache verify/clean
npm login/whoami认证发布/私库访问必备
npm audit / audit fix安全审计结合锁文件修复漏洞
npm ls / prune / dedupe依赖树、裁剪、去重排查幽灵/重复依赖
npm -w/-wsworkspaces 脚本编排-w 选择包；-ws 全部包
npm search搜索包支持关键字、作者、描述等
npm docs查看文档打开包的文档页面
npm repo查看源代码打开包的源代码仓库页面

延伸阅读

npx 了解多少？​

答案
  • npx 是一次性执行包的命令行，npm≥7 中实为 npm exec 的别名，用于无需全局安装即可运行 CLI。
  • 解析顺序：优先使用本地 .bin → 缓存中可用版本 → 临时安装（需 --yes 确认）。支持传入包名与版本。
  • 常用用法：npx <bin>、npx -p <pkg>@<ver> <bin>、npx --no-install 只用本地；npx --yes 静默允许临时安装。
  • 价值：试用/固定版本 CLI、避免全局污染；脚本里可复现地调用工具（pin 版本或只允许本地）。

示例说明:

# 仅使用本地安装的 eslint（无则报错，适合 CI 严格模式）
npx --no-install eslint -v

# 临时拉取指定版本执行（不会全局安装；用 --yes 静默确认）
npx --yes -p typescript@5.4.5 tsc -v

# 多包一次拉取并执行命令（-p 可重复）
npx --yes -p zx@7 -p chalk@5 zx -e 'import chalk from "chalk"; console.log(chalk.green("ok"))'

# npm≥7 等价写法（推荐在脚本中使用，行为更稳定）
npm exec --no -- typescript -v              # 仅本地
npm exec -y -c 'tsc -v'                    # 允许临时安装并执行一段命令

延伸阅读:

有写过 npm 包么，发布一个包涉及哪些流程？​

答案

核心流程包括

  1. 创建账号 账号创建的目的是为了对 registry 具备写权限， 如果想要发布 @scope/xx 作用域包，需要创建一个组织(orgnizations)
  2. 创建 NPM 包
    • 在项目根目录下执行 npm init 命令，生成 package.json 文件
    • 在 package.json 中配置包的名称、版本、描述、入口文件、作者、许可证等信息
    • 确保包名唯一，遵循语义化版本规范（semver）
    • 编写 README.md 说明
    • 编写代码
    • 添加测试、CI 等流程
  3. 调试验证 利用 npm link 和测试验证本地包及相关功能无问题
  4. 发布包
    1. 确保 .npmignore 文件配置正确，避免不必要的文件被打包，可以通过 npm pack --dry-run 进行检查
    2. 执行 npm login 命令登录 NPM 账号
    3. 执行 npm publish 命令将包发布到 NPM Registry
    4. 如果是作用域包，使用 --access public 指定公开访问权限

对于公司内部私有部署的 registry 核心流程基本一致，建议内部采用作用域前缀来和域外 public registry 的包作区分。

提示

不同 NPM 包类型涉及的细节也有所不同，例如：

开发一个高质量的 NPM 包涉及很多细节，可以参考官方的 贡献包到 registry 学习整个流程。相关经验 NPM 包开发经验

什么是 semver 规范，version 中 ~、^ 的含义是什么?​

答案

核心概念:

  • semver（语义化版本规范）是一套用于描述软件版本号的标准，格式为 主版本号.次版本号.修订号（如 1.2.3），分别表示重大变更、功能新增和修复。
  • ~ 和 ^ 是 package.json 中常用的版本范围符号，用于控制依赖包的自动升级策略。
    • ~（波浪号）：允许自动升级最后一位（修订号），如 ~1.2.3 匹配 >=1.2.3 <1.3.0。
    • ^（插入号）：允许自动升级次版本号和修订号（主版本号不变），如 ^1.2.3 匹配 >=1.2.3 <2.0.0（主版本号为 0 时仅升级修订号）。

示例说明:

const semver = require('semver')

// ~1.2.3 允许升级到 <1.3.0
console.log(semver.satisfies('1.2.5', '~1.2.3')) // true
console.log(semver.satisfies('1.3.0', '~1.2.3')) // false

// ^1.2.3 允许升级到 <2.0.0
console.log(semver.satisfies('1.4.0', '^1.2.3')) // true
console.log(semver.satisfies('2.0.0', '^1.2.3')) // false

// ^0.2.3 仅允许升级修订号
console.log(semver.satisfies('0.2.5', '^0.2.3')) // true
console.log(semver.satisfies('0.3.0', '^0.2.3')) // false

Open browser consoleTerminal

面试官视角:

  • 要点：能准确解释 semver 三段含义、~ 和 ^ 的升级范围、实际影响
  • 加分项：能举例说明主版本为 0 的特殊情况、理解依赖升级风险
  • 常见失误：误认为 ^ 可升级主版本、忽略主版本为 0 时的限制、混淆 ~ 和 ^ 匹配范围

延伸阅读:

patch package 是什么如何使用？​

答案

核心概念:

  • patch-package 是一个用于“打补丁”修改 node_modules 依赖包源码的工具，无需 fork 或等待官方修复即可临时修正第三方包 bug 或行为。
  • 工作原理：开发者直接修改 node_modules 下的依赖文件，然后用 patch-package 生成补丁（.patch 文件），补丁随项目提交，团队/CI 复现时自动应用。
  • 典型场景：修复第三方包 bug、临时兼容性调整、等待上游合并 PR 前的过渡方案。

示例说明:

  1. 安装 patch-package 及 postinstall-hook：
npm i -D patch-package
  1. 修改 node_modules/某依赖源码（如修复 bug）。
  2. 生成补丁：
npx patch-package <包名>
  1. 在 package.json 添加 postinstall 钩子，确保每次安装依赖后自动应用补丁：
"scripts": {
  "postinstall": "patch-package"
}
  1. 提交生成的 patches/ 目录到仓库，团队成员/CI 拉取后自动应用补丁。

面试官视角:

  • 要点：能准确描述 patch-package 作用、原理、典型场景与使用流程
  • 加分项：能说明与 fork、yarn patch 等方案的取舍，了解补丁管理风险
  • 常见失误：误以为 patch-package 能自动修复依赖、未提交 patches 目录、忘记 postinstall 钩子导致补丁未生效

延伸阅读: