单纯使用 pnpm 就能实现 Monorepo 项目我们都知道，因为它原生支持 workspace，但是它也依然存在一些缺点，例如：
- 任务运行策略：虽然 pnpm 支持工作空间间的依赖管理和一些任务的并行执行，但是它并不那么灵活或高效地处理跨包的构建、测试和发布任务比如增量构建和任务缓存，可以显著提高大型 Monorepo 的开发和持续集成的效率。
- 自定义构建和发布流程：pnpm 在自定义构建流程、测试流程和发布流程方面的能力有限。对于需要高度定制化工作流的复杂 Monorepo 项目，可能需要额外的脚本或配置来满足这些需求。
- 构建效率：在没有专门的构建缓存机制的情况下，pnpm 对于大型 Monorepo 项目的构建效率可能不如使用了缓存策略的工具。这可能导致在持续集成/持续部署（CI/CD）环境中，构建和部署的时间增长。
- 高级任务调度和资源管理：pnpm 本身可能不提供高级的任务调度和资源管理特性，如限制并行任务数目以避免过度占用系统资源，或者根据任务的资源使用情况动态调整优先级。
尽管 pnpm 为 Monorepo 提供了强大的支持，并且在许多场景下都能很好地工作，但在需要复杂的任务运行策略、细粒度的任务控制以及高效的任务执行优化时，可能会遇到一些问题，在这种情况下我们可能就需要通过额外的工具、脚本或工作流来补充或优化 pnpm 的使用。
什么是 Turborepo
Turborepo 是一个高性能的构建系统，专为 JavaScript 和 TypeScript 的 Monorepo 项目设计。它提供了一种高效管理和构建项目中多个包的方式，通过缓存先前构建和测试的结果来显著减少重复工作的需要，从而加快开发和持续集成的流程。Turborepo 旨在提高大型 Monorepo 项目的构建效率，特别是在复杂的项目中，它可以处理依赖关系、执行任务、并确保构建的正确性和效率。
那么接下来我们将使用 Pnpm 来带大家领略 Turborepo 的魅力！
前言
一、常用工具类型分类
1. 基础修饰类
Partial
将类型 T 的所有属性变为可选。
tsinterface User {
id: number;
name: string;
age: number;
}
type PartialUser = Partial<User>;
// 等价于 { id?: number; name?: string; age?: number }
适用场景：如更新用户信息时，允许部分字段可选。
今天聊聊 Vite+Vue3 生态下最主流的 5 种微前端方案，附代码示例和选型指南，看完直接抄作业～
为啥非得是 Vite+Vue3？
先唠句废话：2025 年还不用 Vite+Vue3 的前端团队，怕是要被卷到沙滩上了。
- 「Vite 的 ES 模块天然优势」：微前端最头疼的 "模块隔离" 和 "资源加载"，在 Vite 的原生 ES 模块支持下直接降维打击 —— 开发环境不用打包，子应用随用随加载，热更新速度比 webpack 快 10 倍不止
- 「Vue3 的 Composition API」：子应用和主应用的状态通信、逻辑复用更灵活，配合 TypeScript 的类型提示，多人协作不容易出乱子
- 「生态成熟度」：2025 年的 Vite 插件生态已经能轻松搞定微前端的样式隔离、路由劫持、依赖共享，比两年前省心太多
在开发者的世界里，版本管理工具一直是我们不可或缺的好帮手。
NVM 虽然经典，但在面对多语言支持和更复杂的项目需求时，显得有些力不从心。今天就为大家介绍几款替代 NVM 的优秀包管理工具，它们功能强大、易于使用，让我们一起来看看吧！
然而，随着项目的多样化和复杂化，传统的 Node.js 版本管理工具 NVM 似乎渐渐无法满足我们的需求。
别担心，今天就为大家介绍几款替代 NVM 的优秀包管理工具，它们功能强大、易于使用，让我们一起来看看吧！
1. VMR
VMR 是一款简单、跨平台且经过良好设计的版本管理器，用于管理多种 SDK 以及其他工具。
它的出现主要是为了解决现有工具无法同时管理多种编程语言的问题。
特点：
- 跨平台：支持 Windows、Linux 和 MacOS。
- 多语言支持：支持多种编程语言和工具，省心省力。
- 友好的 TUI：受到 lazygit 的启发，拥有更友好的文本用户界面（TUI），更符合直觉。
- 项目锁定：支持针对项目锁定 SDK 版本，确保项目稳定性。
- 代理设置：支持反向代理/本地代理设置，提高国内用户下载体验。
有这样一些场景：
- 页面一加载，需要同时发 10 个请求，结果页面卡住，服务器也快崩了。
- 用户可以批量操作，一次点击触发了几十个上传文件的请求，浏览器直接转圈圈。
当后端处理不过来时，前端一股脑地把请求全发过去，只会让情况更糟。
核心思想就一句话：不要一次性把所有请求都发出去，让它们排队，一个一个来，或者一小批一小批来。
这就好比超市结账，只有一个收银台，却来了100个顾客。最好的办法就是让他们排队，而不是一拥而上。我们的“请求队列”就是这个“排队管理员”。
