Link Workspace Packages
Wire new or existing monorepo packages together with the correct npm, yarn, pnpm, or bun workspace command so imports resolve without tsconfig path hacks.
Overview
Link Workspace Packages is an agent skill for the Build phase that links monorepo sibling packages using npm, yarn, pnpm, or bun workspace commands so @org/* imports resolve.
Install
npx skills add https://github.com/nrwl/nx-ai-agents-config --skill link-workspace-packagesWhat is this skill?
- Detect package manager via packageManager field or root lockfile (pnpm, yarn, bun, npm).
- Four-step workflow: identify consumer and provider, add workspace dependency with native syntax, verify node_modules sym
- pnpm requires explicit workspace: protocol; documents pnpm add --workspace and --filter patterns.
- Explicitly avoids patching with tsconfig paths or hand-edited package.json workarounds when resolution fails.
- USE WHEN: new packages, sibling imports, or errors like cannot find module, TS2307, failed to resolve import for @org/*.
- 4-step link workflow (detect PM, consumer, provider, verify symlinks)
Adoption & trust: 1.7k installs on skills.sh; 24 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You imported from a sibling package in a monorepo and the agent keeps tweaking tsconfig paths instead of declaring a real workspace dependency.
Who is it for?
Indie devs on Nx or polyglot JS monorepos who just scaffolded packages or see TS2307 / module not found for internal scopes.
Skip if: Single-package repos, publishing to npm registry without workspaces, or Python/Rust monorepos outside JS package managers.
When should I use this skill?
USE WHEN: (1) you just created or generated new packages and need to wire up their dependencies, (2) user imports from a sibling package and needs to add it as a dependency, (3) you get resolution errors for workspace pa
What do I get? / Deliverables
The consumer package.json lists the provider with proper workspace syntax and node_modules contains verified symlinks so TypeScript and bundlers resolve @org/* cleanly.
- Updated consumer package.json with workspace dependency entry
- Verified symlinks under consumer node_modules
- Resolved @org/* imports without tsconfig path workarounds
Recommended Skills
Journey fit
Broken @org/* resolution blocks implementation; linking sibling packages is core Build work once the repo structure exists. Monorepo package edges are integration plumbing between apps and libraries, not a ship-time security audit task.
How it compares
Package-manager-native linking playbook—not an Nx generator skill and not a substitute for nx.json project graph fixes when projects are unregistered.
Common Questions / FAQ
Who is link-workspace-packages for?
Solo builders and small teams using JS monorepos who want their coding agent to fix workspace linking with pnpm, yarn, npm, or bun instead of brittle path aliases.
When should I use link-workspace-packages?
Use it during Build integrations when you created or generated packages, added a dependency on a sibling @org/* library, or hit cannot find module / failed to resolve import / TS2307 errors.
Is link-workspace-packages safe to install?
The skill only instructs standard package-manager add commands; review the Security Audits panel on this page and run installs in a trusted repo because dependency changes affect your supply chain.
SKILL.md
READMESKILL.md - Link Workspace Packages
# Link Workspace Packages Add dependencies between packages in a monorepo. All package managers support workspaces but with different syntax. ## Detect Package Manager Check whether there's a `packageManager` field in the root-level `package.json`. Alternatively check lockfile in repo root: - `pnpm-lock.yaml` → pnpm - `yarn.lock` → yarn - `bun.lock` / `bun.lockb` → bun - `package-lock.json` → npm ## Workflow 1. Identify consumer package (the one importing) 2. Identify provider package(s) (being imported) 3. Add dependency using package manager's workspace syntax 4. Verify symlinks created in consumer's `node_modules/` --- ## pnpm Uses `workspace:` protocol - symlinks only created when explicitly declared. ```bash # From consumer directory pnpm add @org/ui --workspace # Or with --filter from anywhere pnpm add @org/ui --filter @org/app --workspace ``` Result in `package.json`: ```json { "dependencies": { "@org/ui": "workspace:*" } } ``` --- ## yarn (v2+/berry) Also uses `workspace:` protocol. ```bash yarn workspace @org/app add @org/ui ``` Result in `package.json`: ```json { "dependencies": { "@org/ui": "workspace:^" } } ``` --- ## npm No `workspace:` protocol. npm auto-symlinks workspace packages. ```bash npm install @org/ui --workspace @org/app ``` Result in `package.json`: ```json { "dependencies": { "@org/ui": "*" } } ``` npm resolves to local workspace automatically during install. --- ## bun Supports `workspace:` protocol (pnpm-compatible). ```bash cd packages/app && bun add @org/ui ``` Result in `package.json`: ```json { "dependencies": { "@org/ui": "workspace:*" } } ``` --- ## Examples **Example 1: pnpm - link ui lib to app** ```bash pnpm add @org/ui --filter @org/app --workspace ``` **Example 2: npm - link multiple packages** ```bash npm install @org/data-access @org/ui --workspace @org/dashboard ``` **Example 3: Debug "Cannot find module"** 1. Check if dependency is declared in consumer's `package.json` 2. If not, add it using appropriate command above 3. Run install (`pnpm install`, `npm install`, etc.) ## Notes - Symlinks appear in `<consumer>/node_modules/@org/<package>` - **Hoisting differs by manager:** - npm/bun: hoist shared deps to root `node_modules` - pnpm: no hoisting (strict isolation, prevents phantom deps) - yarn berry: uses Plug'n'Play by default (no `node_modules`) - Root `package.json` should have `"private": true` to prevent accidental publish