参考：

关于现代包管理器的深度思考——为什么现在我更推荐 pnpm 而不是 npm/yarn?

用 pnpm 管理 Monorepo 项目

为什么使用 pnpm 可以光速建立好用的 monorepo（比 yarn/lerna 效率高）
工作空间（Workspace）

基础操作和 npm/yarn 别无二致，但他的特点是：

• 非扁平化，快速，节约资源，使用软链接：不会重复装包
• 支持 monorepo，可以管理多项目，就像 lerna 那样。
• 更加安全，开发中使用的依赖，必须在 package.json 中声明，不准非法访问。
  • 因为 yarn 和 npm 会将所有依赖平铺在 node_modules，在项目中可以访问任何依赖的包。默认配置的 pnpm 创建 node_modules 时不会平铺依赖，我们需要将依赖提升至 node_modules 根目录。
  • 可以这样：创建 ‘<font style="color:rgb(51, 51, 51);">.npmrc</font>‘ 文件 并配置 shamefully-hoist=<font style="color:rgb(170, 13, 145);">true</font>
  • 此配置将所有内容提升到 node_modules 的根目录，如果明确知道需要提升的包名，可以按如下设置

public-hoist-pattern[]=moment
public-hoist-pattern[]=@umijs/*
public-hoist-pattern[]=antd
public-hoist-pattern[]=umi-request

- 还可以使用 `pnpm install --shamefully-hoist`
- 或是自己添加依赖

需要知道的知识点

1、什么是 Monorepo ?

Monorepo是管理项目代码的方式之一，指在一个大的项目仓库（repo）中 管理多个模块/包（package），这种类型的项目大都在项目根目录下有一个 packages 文件夹，分多个项目管理。大概结构如下：

├── packages
|   ├── pkg1
|   |   ├── package.json
|   ├── pkg2
|   |   ├── package.json
├── package.json

目前很很多大型项目采用这样的结构，比如：Babel、vue3和vite等。

Monorepo 的好处在哪里嘞？

• 统一管理。比如微前端项目，多个子应用可以放在同一个monorepo中方便管理；后端用node.js的项目放在monorepo中也可以使用同一套技术栈管理。在 CI/CD 等流水线过程中，方便统一迭代或升级版本，也方便做通用化的配置，适用到多个子项目当中。
• 依赖提升。如果多个项目都依赖了诸如react、vue或TypeScript等常用库，那可以通过lerna或者yarn workspace将依赖提升到最外层，多个子模块/包复用同一个依赖，减小项目体积。

启动

• -w 安装公用依赖
  • pnpm install typescript -D -w
• --filter | -F安装指定子项目独有的依赖
  • pnpm install vue –filter @mono/web
  • 要单独安装，首先要拿到子项目的 package name，在子项目的 package.json 中的 name 上配置，通常是”@命名空间/包名“ 的方式，比如 **<font style="color:rgb(18, 18, 18);background-color:rgb(246, 246, 246);">@vite/xx</font>** 或 **<font style="color:rgb(18, 18, 18);background-color:rgb(246, 246, 246);">@babel/xx</font>**
• <font style="color:rgb(18, 18, 18);background-color:rgb(246, 246, 246);">-C</font> 运行包路径 并运行脚本
  • pnpm -C ./packages/ecs-2.0 start

link

在 monorepo 中，子项目之间可以互相引用的

pnpm i @mono/tools --filter @panda/web

执行后 顺利将 @mono/tools 作为 @mono/web 依赖，但是以 workspace 的方式

"dependencies": {
  "@mono/tools": "workspace:^1.0.0",
}

然后就可以愉快的引用啦

import { getDate } from "@mono/tools";

问题

pnpm.cjs %1 is not a valid Win32 application

参考

在类 Unix 系统中，使用 /usr/bin/env 来查找 node 的路径。然而在 Windows 系统中，这种路径格式会导致错误，因为 Windows 无法识别这种 shebang 行。

Shebang（也称为 hashbang 或 pound-bang）是 Unix 系统中用来指示脚本文件解释器的一种机制。它由一个 # 和一个 ! 组成，后跟解释器的路径。Shebang 通常出现在脚本文件的第一行，用于告诉操作系统该脚本应该由哪个解释器来执行。

1. 将文件 控制台报错会抛出这里的路径\pnpm\bin\pnpm.cjs 顶部的行从：

#!/usr/bin/env node

修改为：（前提是 node 必须是环境变量）

#!node

这个修改告诉 Windows 直接使用系统路径中的 node 可执行文件来运行 pnpm.cjs，从而避免路径错误