Setup TypeScript Library

This documentation was generated with the assistance of AI. Please report any inaccuracies.

Generate the standard npm/TypeScript library toolchain at the repository root — package.json, tsconfig.json, vitest.config.ts, eslint.config.js, .prettierrc/.prettierignore, typedoc.json, and, when opted in, sonar-project.properties and .changeset/config.json — plus a minimal src/index.ts + test/index.test.ts skeleton, from explicit house templates embedded in the skill itself. It announces whether it is creating the toolchain from scratch or updating an existing one, and asks per pre-existing file.

Purpose

iru-setup-typescript-library bootstraps a new npm/TypeScript library’s build/test/lint/docs toolchain from a house template: ESM-only package.json and tsconfig.json (moduleResolution: bundler), Vitest with v8 coverage and an 80%-lines threshold, ESLint 10 flat config (@eslint/js + typescript-eslint recommended
eslint-config-prettier, plus a license-header rule once a license is chosen), Prettier, and Typedoc with treatWarningsAsErrors. Every devDependency version is looked up from the npm registry at run time (Step 4), with a recorded fallback only for when that lookup fails, and npm install is run at the end so the scaffold is immediately buildable. When any owned file already exists it announces "updating an existing setup", warns, and for each such file asks Update (merge, keeping customizations), Keep as is, or Replace (regenerate from the template, losing customizations), explaining each option’s consequences; Stop is offered in the first batch.

Plugin

Shipped by the iru-typescript plugin of the ai-catalog marketplace (install with /plugin install iru-typescript@ai-catalog; see Plugins).

Invocation

/iru-setup-typescript-library

Inputs

Argument Required Description Default

args

No

Pre-resolved parameters passed by an orchestrating skill (e.g. iru-setup-typescript-repository) as newline-separated key: value lines, parsed in Step 0 so this skill doesn’t re-ask about any field already resolved this way.

None — if absent or unrecognized, every field is asked interactively.

package-name

Yes (unless supplied via args)

Unscoped npm package name, e.g. my-library.

None

scope

No

npm scope without the leading @, e.g. example-org. Published name is @<scope>/<package-name> when set, otherwise plain <package-name>.

Unscoped

description

No

One line, used in package.json’s `description field.

Empty, or `gh repo view’s description if available (Step 3)

license

Yes (unless supplied via args)

Resolved via AskUserQuestion: MIT License, Apache License 2.0, No license (UNLICENSED, forces "private": true), or Other (SPDX id asked directly).

None — user must choose

developer-name / developer-email / organization-url

Yes (unless supplied via args)

Populates package.json’s `author object.

None

open-source

No

Whether the repository is open source (yes/no). Drives the recommended defaults for publish and sonar.

Asked first when invoked stand-alone with nothing pre-resolved

publish

No

Whether package.json is configured to publish to the public npm registry (yes/no). Gates publishConfig, .changeset/config.json, and the @changesets/cli devDependency.

yes when open-source; otherwise asked, no recommended

sonar

No

cloud/self-hosted/none — whether to write sonar-project.properties. Plus sonar-organization/ sonar-project-key/sonar-host-url once cloud or self-hosted is chosen.

cloud only when open-source and public; otherwise asked, none recommended

integration-branch

No

The branch Changesets compares against — written as baseBranch into .changeset/config.json, so it is only consulted when publish is yes. iru-setup-typescript-repository forwards the value it collected for the CI workflows so the two agree; stand-alone with publish: yes and no value, the skill asks once instead of silently defaulting.

main

visibility

No

public/private/internal — the GitHub repository’s visibility, used only to key the Sonar recommendation. When absent and the Sonar question is asked, detected via gh repo view, else asked. Open source combined with private/internal is flagged as contradictory. internal counts as private.

Detected or asked (only when Sonar is asked)

ci

No

yes/no — whether the calling run generates GitHub Actions workflows. With ci: no the Sonar question recommends none, since no CI would send reports; if cloud/self-hosted is still chosen, the properties file is written and the report notes that no CI step sends reports.

Unset

on-existing

No

ask/keep/update/replace — one answer applied to every pre-existing owned file, for scripted runs (the warning is still printed).

ask

mode

No

new/existing. existing marks the run as an update in the announcement, but the skill still warns and asks per pre-existing file unless on-existing says otherwise. When an existing package.json supplies identity values, they are used and confirmed in one line instead of asked.

new

Outputs

  • package.json, tsconfig.json, vitest.config.ts, eslint.config.js, .prettierrc, .prettierignore, typedoc.json at the repository root — created, merged (Update), kept, or regenerated (Replace) per file.

  • src/index.ts and test/index.test.ts — a minimal placeholder module and its test, verified to build/test/ lint/typecheck/document clean.

  • sonar-project.properties — only when sonar is cloud or self-hosted; with sonar: none, an existing file is removed on Update/Replace and left in place on Keep (reported as a mismatch).

  • .changeset/config.json — only when publish: yes; with publish: no, same removal/keep rule.

  • node_modules/ from npm install (or pnpm/yarn if that package manager is already in use in the repository), run at the end of Step 7.

  • A report (Step 8) of the mode (from scratch vs update), resolved package identity, the per-file action (created / updated / replaced / kept as is / removed) with mismatches listed for kept files, the visibility used and its source, which devDependency versions came from a live lookup versus the recorded fallback, and explicit warnings to review every generated file, add a LICENSE file if a license was chosen, and set up SONAR_TOKEN/npm publishing credentials before relying on sonar/publish.

Execution flow

flowchart TD A[Start /iru-setup-typescript-library] --> B{"Step 0: args supplied?"} B -- yes --> C[Parse key: value pairs from args] B -- no --> D[Treat every field as unset] C --> E{"Step 1: any owned file\nalready exists?"} D --> E E -- none exist --> E1["Announce: creating\nfrom scratch"] E1 --> F E -- yes --> E2["Announce: updating existing setup;\nlist files found"] E2 --> E3{"on-existing set?"} E3 -- keep/update/replace --> E4["Apply that action\nto every existing file"] E3 -- ask --> H["AskUserQuestion per file:\nUpdate / Keep as is / Replace\n(Stop in first batch)"] H -- stop --> I[Report nothing written; end] H -- choices made --> J["Read existing package.json\nas defaults"] E4 --> J J --> F["Step 2: Collect inputs\n(package-name, scope, description,\ndeveloper info, license, open-source,\npublish, visibility, sonar)"] F --> F2["Ask Update / Keep / Replace for\nsonar-project.properties and\n.changeset/config.json"] F2 --> K["Step 3: Infer repository info\n(owner/repo/host from git remote,\ndescription fallback via gh)"] K --> L["Step 4: Look up devDependency\nversions via npm view\n(TypeScript/@types/node caveats)"] L --> M["Step 5-6: Fill templates and write files\nper file: create / update (show diff) /\nkeep / replace"] M --> N["Step 7: npm install\n(or pnpm/yarn if already in use)"] N --> O["Step 8: Report per-file actions + warn:\nreview before building/publishing"]

Dependencies

Invokes

None — iru-setup-typescript-library is a leaf skill; it does not call any other skill in this catalog. It mentions iru-check-license and iru-setup-typescript-gitignore in its Step 8 report prose, but does not invoke either.

Invoked by

None — this skill runs synchronously; isolation, when used, is applied by its caller (Setup TypeScript Repository), not by this skill itself.

Source

SKILL.md on GitHub — the file this page was generated from.