1. 发布 npm 包 或 npm i git+
# 安装git库做为包
npm i git+https://git.xxx.com/xxx.git#v1.1.1
# 私库可以创建 项目访问令牌（Project Access Tokens） 去install
npm i git+https://[令牌名]:[token]@git.xxx.com/xxx.git#v1.1.1
本地联调时可以使用 npm link
# 组件库目录。为当前项目创建全局连接
sudo npm link
# 目标项目。要使用的包指向全局连接
npm link [someProjectName]
# 组件库目录，删除全局连接
sudo npm unlink [someProjectName]
# 目标项目。删除全局连接
npm unlink [someProjectName]
优点：有版本控制；组件代码安全不混乱；复用方便。
缺点：调试时没有热更新；共用的组件们需单独成功项目，否则 dependencies 是个问题；
// webpack 调试时热更新
{
cache: false,
devServer: {
watchFiles: {
paths: ['**/node_modules/要调试的包/**']
}
}
}
// vite
export default defineConfig({
server: {
watch: {
ignored: ['!**/node_modules/your-package-name/**'],
},
},
// 被监听的包必须被排除在优化之外，
// 以便它能出现在依赖关系图中并触发热更新。
optimizeDeps: {
exclude: ['your-package-name'],
},
})
2. Monorepo 单仓多包
| 常见工具包 | 依赖管理 | 版本管理 | 跨端复用缓存 | |
|---|---|---|---|---|
| Pnpm Workspace | ✅ | 🚫 | 🚫 | 本身支持单体仓库的。没有幽灵依赖和依赖分身问题，这在 Monorepo 中很重要 |
| Rush(4.7k star) | ✅(by pnpm) | ✅ | ✅ | 微软开源，内置 PNPM 以及类 Changesets 发包方案，其插件机制是一大亮点 |
| Turborepo(18k) | 🚫 | 🚫 | ✅ | 专注于[任务编排]，不包含依赖、版本管理的高性能构建系统 |
| 🚫 | ✅ | ✅ | 原作者放弃维护，Nx 接手中... |
Changesets版本及 Changelog 管理的工具前三项都支持局部任务（只构建必须的部分）
pnpm
| npm 命令 | pnpm 等价命令 |
|---|---|
| npm install | pnpm install |
| npm install 包名 | pnpm add 包名 |
| npm uninstall 包名 | pnpm remove 包名 |
| npm run 脚本 | pnpm 脚本 |
所有包安装在全局统一位置，项目以软/硬链接的方式使用，节省硬盘空间和安装时间。node_modules 为非平铺式的，所以不会出现幽灵依赖或依赖分身：
幽灵依赖：项目代码调用了没有安装过的包（eg: dependencies A 依赖了 B，项目中可以直接使用 B，当项目删除 A、或者更换了非平铺式的包管理器时，会报缺少 B 依赖错误，且开发者不能明确 B 使用的版本。更严重情况是，其它开发者明确安装了 B，但版本与 A 的依赖不同，这时 B 版本有可能依赖安装顺序，即不是确定性的，如果在部署时报错还好，否则就会出现一些不好定位和复现的 BUG）
依赖分身：依赖的依赖（比如 B）被重复安装，如果 B 有缓存或副作用，使用结果可能会不符合预期（eg: A 和 C 依赖 B@1.0，M 和 N 依赖 B@2.0，此时只有一个版本的 B 会被提升，另一个版本会被安装两次）
-
依赖地狱：老版本的 npm v3 以下也是非平铺式的，也是当作笑话讲的依赖地狱
npm 依赖地狱pnpm 会在
node_modules下创建.pnpm文件夹，被依赖的包会以软连接或硬连接的方式指向资源。- 软连接 Symbolic link：也称符号链接，可以理解为快捷方式，一个写有目标地址的文件
-
硬连接 Hard link：Linux 中一切皆文件，每个文件有一个自己的编号，称为索引节点，所谓的文件名就是一个系统级别的指向索引节点的指针，所以硬连接可以理解为源文件的别名
依赖以软连接或硬连接的方式指向资源
pnpm 版本与 node 版本对应关系（兼容情况）https://www.pnpm.cn/installation#%E5%85%BC%E5%AE%B9%E6%80%A7
其它与 npm 的区别
Turborepo
# 安装并运行CLI（node 16+?）
npx create-turbo@latest
? 问项目名
? 问包管理器
# 此命令初始化的项目带有示例包
// turbo.json
{
"$schema": "https://turbo.build/schema.json",
"pipeline": {
"build": {
"dependsOn": ["^build"],
"outputs": ["dist/**", ".next/**"] // 命令完成后放入缓存的目录
},
"lint": {
"outputs": []
},
"dev": {
"cache": false
},
"web#dev": {
"dependsOn": ["^build"] // 注意 process.env.NODE_ENV 的值
}
}
}
// package.json
"scripts": {
"build": "turbo run build", // 这些命令需要在pipeline中定义过
"dev": "turbo run dev",
"lint": "turbo run lint" // turbo会查找每个工作区的lint脚本并运行它们
},
"workspaces": [ // 工作区目录
"apps/*",
"packages/*"
],
"workspaces": { // 子项目不需要全局安装的包
"nohoist": [
"@types/react", // 比如vue react混写时，这两个包会影响ts语法检测
"@types/react-dom" // 导致vue项目打包失败
]
},
关于缓存：
当第二次根目录运行
npm run lint时，代码没有改变包，turbo 将读取缓存，不再重新执行turbo 会缓存项目构建结果（
build.outputs）使用
cache: false禁用缓存，比如在 dev 命令中
# 只调试一个项目
npm run dev -- --filter [包名] --filter [包名]
# 只调试 最近提交中有更改的包
turbo run dev --filter=[HEAD^1]
# 忽略缓存，全部重新执行
turbo run build --force
turbo run build --api="https://my-server.example.com" --token="xxxxxxxxxxxxxxxxx"
如果全部缓存了，那到了生产服务器不就下载一下么，即不会真的在服务器上打包，这样到底好不好，得看需求
my-server.example.com官方例子是用 go 写的，看着还有点麻烦
Rush 一个功能全面的庞大的库
3. Bit 一个开源的组件平台
比较庞大，包含 WIKI、设计（原型？）、组件统计和分析等等，它甚至支持微服务架构、无服务器功能、CLI 实用程序、桌面应用程序、原生移动应用程序等等
创建组件还附带一些脚手架。免费版本提供的功能有限。
目前，这个庞大的东西对于我们成本太高
4. Lerna
【目前官方例子运行不起来，网络上有 Lerna 停止维护的传言，GITHUB 上标识维护权限转移给了别人，反正目前比较混乱吧】
针对使用 git 和 npm 管理多软件包代码仓库的一种工具。它可以将不同项目链接起来，并管理它们的发布。
本质上还是方法 1，但省去了 link，依然没有热更新
npm install --global lerna
# 将一个 GIT 仓库转变为一个 Lerna 仓库
lerna init
# 一个标准的 Lerna 仓库目录：
|- packages/
|- package.json
|- lerna.json
package.json中的workspaces: ["packages/*"]批向 Lerna 的工作区（项目列表）目录。packages下的项目们使用dependencies: { "package1": "*" }相互引用。
其它命令：
# 配置工作区，会输出 nx.json
npx lerna add-caching
? Which scripts need to be run in order? # 哪些指令会导致全局构建
❯◉ build
◯ test
◯ dev
◯ start
? Which scripts are cacheable? # 哪些指令可以被缓存
❯◉ build
◯ test
◯ dev
◯ start
? Does the "build" script create any outputs? If not, leave blank, otherwise provide a path relative to a project root (e.g. dist, lib, build,
coverage) # 输出目录
❯dist
# 安装包，packages中重复的包不会被再安装
npm i
# 打包工作区所有项目（按彼此引用顺序）
npx lerna run build
# 打包某个项目
npx lerna run build --scope=package1
# 创建一个新版本，并发布到npm
# 确定当前版本 -> 更新有变化的项目version -> 提交变更并打tag -> 发布到npm
lerna publish
# 检查自上次发布以来哪些软件包被修改过。
lerna changed
# 列出所有或某个软件包自上次发布以来的修改情况。
lerna diff [package?]
# 在每一个包含 [script] 脚本的软件包中运行此命令
lerna run [script]
# 列出所有公共软件包
lerna ls
