How do I install the TS Packaging skill?

Run npx skillmds@latest add fusengine/ts-packaging in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is TS Packaging safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: reads secrets. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with TS Packaging?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is TS Packaging free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published TS Packaging?

fusengine (@fusengine) published this skill. Their other Agent Skills are listed on their SkillMD profile.

TS Packaging by fusengine — Agent Skill

Name: TS Packaging
Rating: 4.666666666666667 (3 reviews)
Author: fusengine

File contents

Out of scope: application deployment (not a library) and framework-owned build pipelines belong to the framework expert's own skills.

TypeScript Packaging

Ship a TypeScript library with a correct exports map, on the right registry.

Agent Workflow (MANDATORY)

Before ANY implementation, spawn 3 agents in parallel, one Agent call each with a name:

fuse-ai-pilot:explore-codebase - Inspect package.json, build output, targets
fuse-ai-pilot:research-expert - Verify latest JSR / npm / Node exports docs via Context7/Exa
mcp__context7__query-docs - Check conditions ordering, attw usage

After implementation, run fuse-ai-pilot:sniper for validation.

Overview

Registry	Format	Publishes	Best for
JSR	ESM only	TS source directly	Deno/Node/Bun libs, doc-rich APIs
npm	ESM (or dual ESM/CJS)	Built `.js` + `.d.ts`	Broadest public reach, CJS consumers

Rule of thumb: internal or Bun/Deno/ESM-only consumer → ESM-pure; broad public library still serving CommonJS → dual ESM/CJS.

Critical Rules

"types" first, "default" last - Conditions match in object order
Match import↔ESM and require↔CJS - Never point require at ESM
One subpath per module - Consistent specifier; set "type": "module" explicitly
Validate with attw - arethetypeswrong before every publish
Provenance on public releases - Publish from CI with id-token: write

Decision Guide

Publishing a TS library?
├── Consumers on Deno/Bun/Node ESM, want source + docs → JSR (ESM only)
│   └── Fix "slow types" (explicit return/prop/const types)
└── Public npm audience
    ├── ESM-only consumers → ESM-pure package.json
    └── Some consumers still on CJS → dual ESM/CJS exports

→ See references/exports-map.md for the conditions model

Reference Guide

Concepts

Topic	Reference	Load when
Exports map & conditions	`references/exports-map.md`	Writing the `exports` field
JSR publishing	`references/jsr-publishing.md`	Publishing TS source to JSR
npm publishing	`references/npm-publishing.md`	Publishing to npm (dual/ESM)
Type validation	`references/validation.md`	Checking types resolve correctly

Templates

Template	Use Case
`references/templates/package-json-dual.md`	Dual ESM/CJS + ESM-pure package.json
`references/templates/jsr-json.md`	jsr.json with multi-entry exports
`references/templates/publish-workflow.md`	GitHub Actions release with provenance

Quick Start

Modern exports (ESM-pure)

{
  "type": "module",
  "exports": {
    ".": { "types": "./dist/index.d.ts", "default": "./dist/index.js" }
  }
}

Validate before publish

npx @arethetypeswrong/cli --pack

→ See references/validation.md

Best Practices

DO

Set "type" explicitly, even for CJS packages
Provide types in every conditional branch
Publish from CI so provenance is automatic

DON'T

Ship dual CJS when every consumer is ESM (dead weight)
Order "default" before "types" (breaks type resolution)
Use --allow-slow-types on JSR as a habit (degrades docs + npm compat)

---name: ts-packagingdescription: Use when publishing a TypeScript library — exports map, JSR vs npm, dual ESM/CJS, type validation, provenance. Not for application deployment.---<objective>This skill covers shipping a TypeScript library correctly: designing the exports map and itsconditions ordering (types first, default last), choosing JSR (ESM-only, publishes TS sourcedirectly, fixes 'slow types') versus npm (built .js + .d.ts, optionally dual ESM/CJS forCommonJS consumers), validating resolved types with arethetypeswrong (attw) before everypublish, and enabling provenance on public releases via CI with id-token: write.Out of scope: application deployment (not a library) and framework-owned build pipelinesbelong to the framework expert's own skills.</objective># TypeScript PackagingShip a TypeScript library with a correct exports map, on the right registry.## Agent Workflow (MANDATORY)Before ANY implementation, spawn 3 agents in parallel, one `Agent` call each with a `name`:1. **fuse-ai-pilot:explore-codebase** - Inspect package.json, build output, targets2. **fuse-ai-pilot:research-expert** - Verify latest JSR / npm / Node exports docs via Context7/Exa3. **mcp__context7__query-docs** - Check conditions ordering, attw usageAfter implementation, run **fuse-ai-pilot:sniper** for validation.---## Overview| Registry | Format | Publishes | Best for ||----------|--------|-----------|----------|| JSR | ESM only | TS **source** directly | Deno/Node/Bun libs, doc-rich APIs || npm | ESM (or dual ESM/CJS) | Built `.js` + `.d.ts` | Broadest public reach, CJS consumers |Rule of thumb: internal or Bun/Deno/ESM-only consumer → **ESM-pure**;broad public library still serving CommonJS → **dual ESM/CJS**.---## Critical Rules1. **`"types"` first, `"default"` last** - Conditions match in object order2. **Match `import`↔ESM and `require`↔CJS** - Never point `require` at ESM3. **One subpath per module** - Consistent specifier; set `"type": "module"` explicitly4. **Validate with attw** - `arethetypeswrong` before every publish5. **Provenance on public releases** - Publish from CI with `id-token: write`---## Decision Guide```Publishing a TS library?├── Consumers on Deno/Bun/Node ESM, want source + docs → JSR (ESM only)│ └── Fix "slow types" (explicit return/prop/const types)└── Public npm audience ├── ESM-only consumers → ESM-pure package.json └── Some consumers still on CJS → dual ESM/CJS exports```→ See `references/exports-map.md` for the conditions model---## Reference Guide### Concepts| Topic | Reference | Load when ||-------|-----------|-----------|| Exports map & conditions | `references/exports-map.md` | Writing the `exports` field || JSR publishing | `references/jsr-publishing.md` | Publishing TS source to JSR || npm publishing | `references/npm-publishing.md` | Publishing to npm (dual/ESM) || Type validation | `references/validation.md` | Checking types resolve correctly |### Templates| Template | Use Case ||----------|----------|| `references/templates/package-json-dual.md` | Dual ESM/CJS + ESM-pure package.json || `references/templates/jsr-json.md` | jsr.json with multi-entry exports || `references/templates/publish-workflow.md` | GitHub Actions release with provenance |---## Quick Start### Modern exports (ESM-pure)```json{ "type": "module", "exports": { ".": { "types": "./dist/index.d.ts", "default": "./dist/index.js" } }}```### Validate before publish```bashnpx @arethetypeswrong/cli --pack```→ See `references/validation.md`---## Best Practices### DO- Set `"type"` explicitly, even for CJS packages- Provide `types` in every conditional branch- Publish from CI so provenance is automatic### DON'T- Ship dual CJS when every consumer is ESM (dead weight)- Order `"default"` before `"types"` (breaks type resolution)- Use `--allow-slow-types` on JSR as a habit (degrades docs + npm compat)

Frequently asked questions

TS Packaging