tsdown-package
skill✓Migrates a monorepo package from `tsup` to `tsdown`. Use when asked to migrate a package to `tsdown` and the package has used `tsup` thus far.
apm::install
apm install @prisma/tsdown-packageapm::skill.md
---
name: tsdown-package
description: Migrates a monorepo package from `tsup` to `tsdown`. Use when asked to migrate a package to `tsdown` and the package has used `tsup` thus far.
---
# tsdown Package Skill
## Instructions
Follow the information in `@prisma-next/tsdown`'s `README.md` file.
Verify the package's contract didn't break - same exposed paths, builds and tests are still passing.
## Exports Convention (required)
Use one convention by default:
- Prefer auto-generated `package.json#exports` from `@prisma-next/tsdown` base config.
- Keep `exports.enabled` untouched (inherits `'local-only'` from base config).
- Model public subpaths via `entry`, then run `pnpm build` and commit generated `exports`.
## Entry Mapping Rules
- Prefer explicit object `entry` when root `.` must map to a file under `src/exports/*`:
- `'.': 'src/exports/index.ts'`
- `'foo/bar': 'src/foo/bar.ts'`
- Use array `entry` only when default tsdown path inference already produces the expected public subpaths.
- Keep CLI entrypoints in `entry` when needed for bin output, and rely on base `exclude` to avoid exposing them as imports.
## When `exports.enabled: false` is allowed
Use manual exports only when auto-generation cannot preserve required behavior, such as:
- non-code export subpaths (for example JSON schema assets),
- legacy root/subpath contracts that cannot be represented through `entry` mapping without changing runtime semantics,
- intentionally custom dist layouts that diverge from base mapping behavior.
If an exception is required:
- add a short reason comment in `tsdown.config.ts`,
- keep manual `package.json#exports` minimal,
- avoid introducing new manual-export packages unless strictly necessary.
## Migration Checklist
1. Migrate `tsup.config.ts` -> `tsdown.config.ts`.
2. Switch build script to `tsdown`.
3. Apply the exports convention above (auto-generated by default).
4. Build package(s) and review generated `package.json#exports`.
5. Verify public import paths remain stable (`.` + required subpaths).
6. Run package tests/typecheck and confirm no contract drift.