setup-ts-deep-modules

Organizes a TypeScript project so each piece hides its code inside and only shows what others need to use.

Installation
Run `npx skills add "https://github.com/christofferbergj/agent-skills" --skill "setup-ts-deep-modules"` to install this skill, then follow its SKILL.md instructions for my next request.

Paste this into Claude Code, Cursor, or any agent that can run commands.

SKILL.mdShow the author's original SKILL.md
---
name: setup-ts-deep-modules
description: Wire dependency-cruiser into a TypeScript repo so each package is a deep module, with implementation hidden in subfolders and reachable only through its entry-point files. User-invoked.
disable-model-invocation: true
---

# Setup TS Deep Modules

Make every package in this repo a **deep module**: a lot of behaviour behind a small interface. A package's public surface is its **entry points** (the files at the package root), and everything in its subfolders is hidden. This skill installs [dependency-cruiser](https://github.com/sverweij/dependency-cruiser) and the rules that make the entry points the only way in, then proves the rules bite.

For the vocabulary (deep module, interface, seam, depth), invoke /codebase-design and use its language throughout.

## The shape this enforces

```
src/packages/
  <name>/
    index.ts        ← an entry point (public). Import this from outside.
    client.ts       ← another entry point. Packages may expose SEVERAL.
    lib/            ← implementation: hidden from outside, free to import each other.
    tests/          ← co-located tests + fixtures (a subfolder, so private).
```

The public surface is the package's **root files**, not one designated `index.ts`. By convention implementation lives in `lib/` and tests in `tests/`, giving every package the same two-folder shape. The rule itself is general, though: _anything_ in _any_ subfolder is private, so you never extend the config to add a folder.

Five configured checks, all `error`, implement these policy families:

1. **Entry-point boundary**: code outside a package (app code or another package) may import only that package's entry points (its root files), never anything in its subfolders.
2. **Intra-package freedom**: a package's own files import each other freely.
3. **Tests through the entry points**: files under `<pkg>/tests/` may import any package's entry points and their own `tests/` fixtures, but never any package's subfolder internals (not even their own). Integration tests across packages are fine; deep imports are not.
4. **No cycles**: no dependency cycles.

**Entry points, not a barrel.** Because the public surface is _every_ root file, a package can expose several small entry points (`index.ts`, `client.ts`, `server.ts`) instead of funnelling everything through one giant `index.ts`. Barrel files that re-export a whole subtree are discouraged; keep entry points small and hide implementation in subfolders.

Layering (which packages may depend on which) is a _different_ concern and is left as a commented stub in the config for this repo to fill in.

## Steps

### 1. Detect the environment

- **Package manager**: `pnpm-lock.yaml` → pnpm, `yarn.lock` → yarn, `bun.lock` or `bun.lockb` → bun, else npm. Use it for every command below (`pnpm`/`yarn`/`npm run`/`bunx`).
- **Packages root**: prefer the repository's actual package/workspace layout; use `src/packages` only when it is the agreed target. Confirm the choice with the user if the repo already has a different obvious convention.
- **Existing config**: check for a `.dependency-cruiser.*` file. If one exists, do **not** overwrite it: merge the five checks and the options in, and tell the user what you added.

**Done when:** package manager, packages root, and existing-config status are all known.

### 2. Install dependency-cruiser

Check the selected dependency-cruiser version's Node engines and supported TypeScript compiler range against the repository. Install it as a devDependency with the detected package manager. Preserve the project's compiler version; resolve an incompatible tool version or required migration before enabling the check.

**Done when:** `dependency-cruiser` is in `devDependencies` and can parse this repository's actual TypeScript compiler version.

### 3. Write the config

Copy [`dependency-cruiser.config.cjs`](./dependency-cruiser.config.cjs) to the repo root as `.dependency-cruiser.cjs`. Set `PACKAGES_ROOT` to the root detected in step 1. The template assumes flat packages and tests in `tests/`. Verify those assumptions, escape any regular-expression characters in the root, and adapt actual entry points and TypeScript configuration before enabling it.

**Done when:** `.dependency-cruiser.cjs` exists with the correct `PACKAGES_ROOT`, and the required forbidden rules are present.

### 4. Wire it into the checks

- Add a `lint:boundaries` script that scans the packages and every source root that can import them. For the default `src/packages` layout, use `depcruise src`; for separate workspace trees, pass all relevant roots, such as `depcruise packages apps`. Scanning only the packages misses outside importers and cannot enforce `entrypoint-boundary-from-app`.
- Fold it into the repo's umbrella check command, the one that already runs typecheck (e.g. a `check` / `ci` / `validate` script). Do **not** touch `tsconfig` or add path aliases.
- If there is no umbrella script, add `lint:boundaries` and tell the user to include it in CI.

**Done when:** `lint:boundaries` scans the packages and their external importers and runs as part of the same command as typecheck.

### 5. Scaffold the example package

Use a small existing package or an isolated temporary fixture to prove the policy. Create a committed `<packages-root>/example/` starter only when the user requests one:

- `index.ts` is an entry point. Export one function that delegates to an internal file (so the package is visibly _deep_, not a pass-through).
- `lib/impl.ts`: an internal file in a **subfolder**, imported by `index.ts`, not reachable from outside.
- `tests/example.test.ts` imports **only** `../index` (an entry point) and asserts against the public function.

Keep temporary proof files outside the delivered product. A requested starter is explicitly labeled as such.

**Done when:** the selected proof package exposes behavior through its intended public entry points.

### 6. Prove the rules bite

This is the completion criterion for the whole skill: a config that doesn't fail on a violation is worthless.

1. Run `lint:boundaries`. It must **pass** on the clean proof package and report the expected source modules and dependencies across the chosen roots. Zero scanned files or a missing-transpiler warning is a failed setup even with exit code zero.
2. Temporarily add a deep import to the proof package's test (e.g. `import { thing } from "../lib/impl"`). Run `lint:boundaries`; it must **fail** with `tests-through-entrypoints`. Restore the test, run again, and require a pass.
3. Temporarily add a deep import from a source file outside the packages root to the proof package's internal file. Use an existing app importer or a disposable fixture within a chosen scanned source root. Run `lint:boundaries`; it must **fail** with `entrypoint-boundary-from-app`, and the output must include that importer. Restore or remove the fixture, run again, and require a pass.

**Done when:** both intentional deep imports have produced their expected failures, each restoration passes, and the final scan covers the packages and their external importers. If either violation is missed, fix the scan roots or rules before finishing.

### 7. Document the convention

Write a `README.md` **in the packages folder** (`<packages-root>/README.md`, next to the packages it governs) covering: the `src/packages/<name>/` layout (entry points at the root, `lib/` for implementation, `tests/` for tests), "import only through a package's entry points (its root files)", and how to run `lint:boundaries`. **Discourage barrel files** explicitly: expose several small entry points instead of re-exporting a whole subtree through one index. Keep it to the copy-me snippet plus the policy families in one paragraph each.

Invoke /domain-modeling for any changed project ownership or vocabulary. Then add a **context pointer** to it from the repo's agent-instructions file (`CLAUDE.md` if present, else `AGENTS.md`, creating `AGENTS.md` if neither exists). One line is enough, e.g. `Packages are deep modules: see [src/packages/README.md](./src/packages/README.md) before adding or importing one.` This is what makes an agent discover the boundary rule instead of tripping over it.

**Done when:** `<packages-root>/README.md` exists and discourages barrels, and the repo's `CLAUDE.md`/`AGENTS.md` links to it.

## Notes

- The config's `$1` back-references (dependency-cruiser's group matching) are what let a package reach its own internals while outsiders can't. Don't flatten them into separate per-package rules.
- Public vs private is decided by **depth**: a package's root files are entry points; anything in a subfolder is private. The conventional subfolders are `lib/` (implementation) and `tests/`, but the rule doesn't hardcode them: any subfolder is private, so a new folder never needs a config change. Adding an entry point is just adding a root file (no barrel).
- Packages are **flat**: one tier of immediate children under the root. A package's internals may nest as deep as you like; a package may not contain another package.
- Use `.cjs` (not `.js`) so the config's `module.exports` works even in `"type": "module"` repos.

Ships with 4 supporting files:

  • agents/openai.yaml
  • dependency-cruiser.config.cjs
  • LICENSE
  • UPSTREAM.md

Mirrored from the author's public source. Install counts from the open skills registry.

The systems behind these skills get built for partners every week.

Partner with us