大家好,我是刘布斯。
咱们之前的文章,其实介绍过 pnpm 和 Monorepo,结合起来就是一个很有趣的面试问题“你们团队为什么要用 pnpm + monorepo?”。
在大厂前端面试中,“pnpm + monorepo” 这个话题出现频率极高,不仅是因为它是近几年前端工程化的“香饽饽”,更因为它背后涉及到依赖管理、包构建优化、团队协作模式、代码复用等一整套工程化理念。
面试官喜欢问它,有两个原因:
所以,如果你能在面试里用简单的语言,把 pnpm + monorepo 的原理和价值讲清楚,你的工程化能力会直接加分。
pnpm + monorepo 的组合,主要出现在以下场景:
简单来说,如果你项目规模大到一个仓库装不下的依赖关系,就该考虑 pnpm + monorepo 了。
pnpm(Performant npm)最大的特点是:它不是把依赖直接复制到 node_modules
,而是将依赖安装到全局存储(store)中,然后通过硬链接(hard link)指向项目。
核心原理:
pnpm install
# 全局 store:~/.pnpm-store
# node_modules 内是硬链接,不会重复占用磁盘空间
硬链接(Hard Link):文件系统中的一个引用,本质上多个路径指向同一个物理文件。
好处:
重要补充:pnpm 为了保证 node_modules
的结构稳定,采用了一种 严格的模块隔离机制,防止不同依赖隐式共享包(npm/yarn 会产生幽灵依赖问题)。
Monorepo(单仓多包)是将多个相关项目放在一个 Git 仓库里,通过 workspace 管理它们之间的依赖与构建。
在 pnpm 中,只需要在 pnpm-workspace.yaml
配置:
packages:
- "packages/*"
- "apps/*"
node_modules
,避免版本冲突。build
。举个例子,如果你的 UI 库更新了一个组件,业务项目立刻就能用最新版本测试,而不需要走完整的 npm 发布流程。
在大型 monorepo 里,构建速度是个大坑。pnpm 结合 TurboRepo / Nx 可以做到按需构建:
代码示例(turbo.json):
{
"pipeline": {
"build": {
"outputs": ["dist/**"],
"dependsOn": ["^build"]
}
}
}
这样,当你改了 packages/utils
,只会构建依赖它的业务包,其他部分直接跳过。
综合下来,原因主要有:
pnpm + monorepo 的核心价值在于:
它把依赖管理和多包协作的痛点,一次性解决到了工程化的骨子里。
pnpm 解决的是依赖安装速度与一致性,monorepo 解决的是多项目协作与代码复用,两者结合,既快又稳,特别适合大型团队和复杂项目架构。
如果在面试中遇到这个问题,可以这样组织回答:
还没有使用过我们刷题网站(https://fe.ecool.fun/)或者刷题小程序的同学,如果近期准备或者正在找工作,千万不要错过,题库主打无广告和更新快哦~。
有会员购买、辅导咨询的小伙伴,可以通过下面的二维码,联系我们的小助手。