简单介绍

国庆前发了个动态，要把之前没完成的项目完成首先放上项目🔗@abmao/pkgs，该项目定位是一个足够简单的主打版本控制的包控制器，不针对是否 Monorepo 还是 MultiRepo 项目，因为它是以包为单位做管理，并不归类为 Monorepo 管理工具。

问答？

有人问为什么要重新做一个这种工具，市面上已经有多个成熟的 Monorepo 管理工具

答：这个项目启动当时的场景是 lerna 不维护了，当时又不支持 workspace 协议。而 changesets 会在项目产生额外的文件，我并不喜欢这种入侵式，会有一种脏乱的感觉，更喜欢 lerna 那种基于 git tag 做管理。而 rush 当时文档过少，解决问题门槛会相对较高，还有一个重点问题是，我并不喜欢它们做多余的事，rush 和 lerna 的功能跟包管理器有重叠，会导致开发者在使用上不统一，会提高心智负担，这一点 lerna 的文档现在也提倡使用包管理器功能优先

@abmao/pkgs有什么特别？

📦 repo 抹平：以包为单位进行管理
🎁 开箱即用：0配置语义化运行
🐚 只做本分：配合包管理器各司其职
🎛️ 按需调用：基于 git 的按需调用
🔌 插件化：支持自定义插件

repo 抹平

上面提到关于无论 Monorepo 还是 MultiRepo 都可以使用，然后有人就会疑问，我不是 Monorepo 我为什么用它？

👆🏻这是其中的原因之一

原因二：一说到 Monorepo 就会出现一个局限，lerna、changesets、rush 都是用来解决 Monorepo 带来的问题，如果是 MultiRepo，我为啥要用？所以，从定位上就是与上方3个不同，无论你的项目是多个还是单个，如果它需要版本升级、需要版本发布，那么你就用得上 @abmao/pkgs，在项目类型上统一了管理方式

开箱即用

无需配置，开箱即用，会基于语义化及包管理器的配置文件做解析。

npm i @abmao/pkgs -g
pkgs init
pkgs version
pkgs publish

只做本分

初衷就是做一个功能不重叠，与包管理器相互配合的包控制器，前者负责管理依赖，后者负责包版本处理，分工明确

按需调用

@abmao/pkgs 的按需调用是基于 git 仓库 封装，有多种按需调用模式，分别有工作区、暂存区和版本库和所有，当命令运行后@abmao/pkgs 对 git 各区域影响的文件做筛查、依赖追踪和拓扑排序，依次运行包命令

// 默认 all,对所有包运行 test 命令
pkgs run test
// 对版本区受影响的包运行 test 命令
pkgs run test --type=repository
// 对暂存区受影响的包运行 test 命令
pkgs run test --type=stage
// 对工作区受影响的包运行 test 命令
pkgs run test --type=work

为啥需要按需调用？

当你的项目有上百个包，我修改了 a包，b、c、e等数十个不等的包直接依赖或者间接依赖着a，这时候你需要运行测试命令test，对修改后的包及受影响的包运行测试，你会怎么做？

用pnpm test --filter=xx，每次都要手动指定，非常麻烦，依赖过多很容易忘记
用lerna run test --since=origin/main，维度没有 @abmao/pkgs 丰富

插件化

内部命令皆由插件组成，同样你可以注册插件到 @abmao/pkgs 上，基于 @abmao/pkgs 能力做扩展，例如打印项目的包依赖关系、获取修改文件影响到的包。相关文档

// pkgs.config.ts
import { Mode, defineConfig } from '@abmao/pkgs'
import createPackagesPlugin from './scripts/packages'

export default defineConfig({
  // 加载插件
  plugins: [
    // 支持函数
    createPackagesPlugin,
    // 支持包名
    'createModulePlugin',
    // 支持路径
    path.resolve(__dirname, './scripts/packages.ts'),
  ],
})

新一代最容易上手的 Monorepo 管理器❎