DevLink — Cross-repo dependency manager

One line: Flip an entire monorepo of git submodules between link:../../path (local development) and ^1.2.3 (published npm versions) with one command.

Source: plugins/kb-labs-devlink

The problem

If you split a project across multiple git repos but want them to feel like one workspace, you hit this problem fast: your package.json files need to reference each other one way during development (local symlinks, instant code changes) and another way for CI/publishing (versioned npm packages).

Doing this by hand is doable for two repos. By the time you have eighteen, every "switch mode" turns into 30 minutes of sed and broken pnpm install.

DevLink turns it into one command.

What it does

# Switch every cross-repo dep to local link: mode (development)
pnpm kb devlink switch --mode=local --install
 
# Switch back to npm versions (before publishing)
pnpm kb devlink switch --mode=npm
 
# Preview without applying
pnpm kb devlink switch --mode=local --dry-run
 
# Limit to specific repos
pnpm kb devlink switch --mode=npm --repos=kb-labs-cli,kb-labs-core
 
# See current state and diagnose drift
pnpm kb devlink status
 
# Undo the last switch
pnpm kb devlink undo

The --install flag triggers pnpm install at the root and inside each touched sub-repo, so you go from "wrong state" to "working state" in one step.

Architecture sketch

devlink:switch
  ├─ scan all package.json under monorepo
  ├─ for each cross-repo @kb-labs/* dep:
  │     local mode → "link:../../path/to/repo"
  │     npm mode   → "^x.y.z" from registry
  ├─ regenerate sub-repo pnpm-workspace.yaml files
  ├─ delete stale lockfiles
  ├─ write backup → .kb/devlink/backups/<timestamp>/
  └─ optional: pnpm install (root + per-repo)

The backup is the safety net — every switch can be undone with devlink undo, which restores package.json files and lockfiles from the most recent backup.

KB Labs primitives used

From the manifest, DevLink is the smallest of the four — it barely needs the platform at all:

platform: {
  requires: ['storage'],
  optional: [],
},

• storage — for backups and state.
• cache — namespace devlink:, used to memoize parsed package.json and registry lookups across runs of the same monorepo.
• No LLM, no network. DevLink is a pure file-system tool.
• Filesystem permissions — scoped to **/package.json, **/pnpm-workspace.yaml, and .kb/devlink/**. The plugin physically cannot touch source files.
• CLI commands — devlink:switch, devlink:status, devlink:plan, devlink:freeze, devlink:undo, devlink:backups.

What to steal

Backups before destructive ops. Every command that modifies files writes a versioned backup first, and devlink undo is a first-class command — not a flag. This is the right pattern for any plugin that touches user-owned files: apply should be cheap to reverse, and reversing should be one command, not "restore from git".

It also shows that a useful KB Labs plugin doesn't have to use AI. The platform's value here is pure plumbing: permission scoping, manifest discovery, CLI registration, scoped filesystem access. DevLink is an example of "I had a chore script, I made it a plugin, now everyone on the team has the same command".

Going deeper

• Manifest source
• Guide: Your First Plugin — DevLink is a good "non-AI" template to study