AgentStack
Browse Sign in
Browse Why AgentStack Sell Docs
Sign in
SKILL verified MIT Self-run

Ts Tsconfig Modern Strict Starter

skill-kongyo2-agent-primary-ts-starters-src-ts-tsconfig-modern-strict-starter · by kongyo2

Set up a TypeScript tsconfig.json with modern (ESNext + bundler/nodenext) and maximally strict settings, tuned so that `tsc --noEmit` becomes a fast, reliable inner feedback loop for the LLM agent doing the editing. Use whenever a tsconfig.json is being created, edited, reviewed, troubleshot, or even just discussed — apply the standing policy even when the user only asks about a single option. De…

No reviews yet
0 installs
23 views
0.0% view→install

Install

$ agentstack add skill-kongyo2-agent-primary-ts-starters-src-ts-tsconfig-modern-strict-starter

✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access No
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets No
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

View the full security report →

Verified badge

Passed review? Show it. Paste this badge into your README, it links to the public security report.

AgentStack Verified badge Links to your public security report.
[![AgentStack Verified](https://agentstack.voostack.com/badges/verified.svg)](https://agentstack.voostack.com/security/report/skill-kongyo2-agent-primary-ts-starters-src-ts-tsconfig-modern-strict-starter)

Reliability & compatibility

Security review passed
0 installs to date
no reviews yet
4mo ago

Declared compatibility

Claude CodeClaude Desktop

Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.

Preview Execution monitoring

We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.

How agent discovery & health will work →
Are you the author of Ts Tsconfig Modern Strict Starter? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

TS + npm tsconfig Modern Strict Starter (Agent-Friendly)

Use whenever a tsconfig.json is being created, edited, reviewed, or troubleshot in a TypeScript npm project. In a monorepo, edit the workspace the user names — ask if it isn't named.

The standing policy below is tuned so that tsc --noEmit is the LLM agent's primary inner feedback loop. Modern syntax + maximum strictness narrows the surface where an agent can ship a silent bug; explicit module resolution removes whole classes of "why isn't this importing" turns that would otherwise burn agent context; incremental: true keeps the loop fast enough to run between each edit.

Standing Policy (override only with a stated reason)

  • "target": "esnext". Downleveling is the bundler / runtime's job, not tsc's.
  • "strict": true plus every recommended add-on flag below.
  • "moduleResolution": "bundler" for app code via a bundler; "nodenext" for code running on Node directly.
  • "skipLibCheck": true. Always — a single broken .d.ts in node_modules otherwise stops the entire feedback loop.
  • "incremental": true (or "composite": true under project references). The .tsbuildinfo cache makes the second-and-onward tsc --noEmit run near-instant, which is what keeps the agent loop tight enough to run between edits.
  • "isolatedModules": true and "verbatimModuleSyntax": true for any code touched by esbuild / SWC / Babel / Vite.

When the user proposes loosening any of these, ask what concrete problem they are solving before agreeing.

Pick the Use Case First

Resolve the use case before writing or modifying a tsconfig — the four templates differ in incompatible ways.

Is tsc emitting JS?
├── No, a bundler emits  ─────────────────► §1  Browser app + bundler
└── Yes, tsc emits
    ├── Running on Node directly (ESM)  ──► §2  Node ESM app
    └── Publishing to npm
        ├── Single package           ────► §3  Library
        └── Monorepo                 ────► §4  Project references

The target / module / moduleResolution Trio

Co-dependent. Pick one row, don't improvise.

| Scenario | target | module | moduleResolution | | ------------------------------------- | --------- | ------------ | ------------------ | | Browser app via bundler | esnext | esnext | bundler | | Node.js native ESM | esnext | nodenext | nodenext | | Publishable library (build via tsc) | es2020+ | esnext | bundler | | Node.js CommonJS (legacy) | es2022 | commonjs | node |

Common mismatches:

  • module: "commonjs" + moduleResolution: "bundler" — invalid combination.
  • nodenext + extensionless relative imports — Node ESM requires .js on relative imports even when the source is .ts.

§1. Browser app + bundler (Vite, Next.js, Rspack, etc.)

{
  "compilerOptions": {
    "target": "esnext",
    "module": "esnext",
    "moduleResolution": "bundler",
    "lib": ["esnext", "dom", "dom.iterable"],
    "jsx": "react-jsx",

    "noEmit": true,
    "incremental": true,
    "isolatedModules": true,
    "verbatimModuleSyntax": true,
    "resolveJsonModule": true,
    "allowImportingTsExtensions": true,

    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true,
    "skipLibCheck": true,

    "strict": true,
    "noUncheckedIndexedAccess": true,
    "exactOptionalPropertyTypes": true,
    "noImplicitOverride": true,
    "noImplicitReturns": true,
    "noFallthroughCasesInSwitch": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "allowUnreachableCode": false,
    "allowUnusedLabels": false
  },
  "include": ["src"]
}

Drop "dom" and "dom.iterable" from lib for non-browser code. Change jsx to "preserve" plus jsxImportSource for Preact / Solid.

§2. Node.js ESM application

package.json must have "type": "module". Relative imports require .js even when the source is .ts.

{
  "compilerOptions": {
    "target": "esnext",
    "module": "nodenext",
    "moduleResolution": "nodenext",
    "lib": ["esnext"],

    "outDir": "./dist",
    "rootDir": "./src",
    "sourceMap": true,
    "incremental": true,

    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true,
    "skipLibCheck": true,
    "resolveJsonModule": true,
    "isolatedModules": true,
    "verbatimModuleSyntax": true,

    "strict": true,
    "noUncheckedIndexedAccess": true,
    "exactOptionalPropertyTypes": true,
    "noImplicitOverride": true,
    "noImplicitReturns": true,
    "noFallthroughCasesInSwitch": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true
  },
  "include": ["src/**/*"],
  "exclude": ["**/*.test.ts", "**/*.spec.ts", "dist"]
}

§3. Publishable library

{
  "compilerOptions": {
    "target": "esnext",
    "module": "esnext",
    "moduleResolution": "bundler",

    "rootDir": "./src",
    "outDir": "./dist",
    "declarationDir": "./dist-types",
    "declaration": true,
    "declarationMap": true,
    "sourceMap": true,
    "incremental": true,
    "allowImportingTsExtensions": false,

    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true,
    "skipLibCheck": true,
    "isolatedModules": true,
    "verbatimModuleSyntax": true,

    "strict": true,
    "noUncheckedIndexedAccess": true,
    "exactOptionalPropertyTypes": true,
    "noImplicitOverride": true,
    "noImplicitReturns": true,
    "noFallthroughCasesInSwitch": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true
  },
  "include": ["src/**/*"],
  "exclude": ["**/*.test.ts", "**/*.spec.ts"]
}

When publishing, also configure package.json exports — the types field must come first inside each conditional block.

§4. Monorepo with project references

Root tsconfig.json:

{
  "files": [],
  "references": [
    { "path": "./packages/core" },
    { "path": "./packages/utils" },
    { "path": "./packages/app" }
  ]
}

Each package extends a shared base and sets composite: true:

{
  "extends": "../../tsconfig.base.json",
  "compilerOptions": {
    "composite": true,
    "rootDir": "./src",
    "outDir": "./dist",
    "declaration": true,
    "declarationMap": true
  },
  "include": ["src/**/*"],
  "references": [{ "path": "../core" }]
}

Build with tsc --build (or tsc -b). Plain tsc against the root won't resolve references.

Strict Flags Beyond strict: true

These are not enabled by strict: true but should be on by default for an agent-primary workflow:

  • noUncheckedIndexedAccessarr[i] and obj[k] become T | undefined. Catches a class of silent index bugs that agents emit easily.
  • exactOptionalPropertyTypes?: no longer accepts an explicit undefined.
  • noImplicitOverride — subclass overrides must say override.
  • noImplicitReturns — all branches return when any branch does.
  • noFallthroughCasesInSwitch — no silent fallthrough.
  • noUnusedLocals / noUnusedParameters — agent leftovers get caught at type-check. For unused parameters in interface implementations, prefix with _ instead of disabling the flag globally.
  • allowUnreachableCode: false / allowUnusedLabels: false — treat as errors, not warnings.

When the toolchain supports it, also add verbatimModuleSyntax (any non-tsc transpiler), isolatedDeclarations (TS 5.5+ library), erasableSyntaxOnly (TS 5.8+ type-strip runtime).

Agent Inner Loop

Add to package.json so the agent has a single command for the type-check feedback loop:

{
  "scripts": {
    "typecheck": "tsc --noEmit",
    "typecheck:watch": "tsc --noEmit --watch"
  }
}

With incremental: true set, the second-and-later npm run typecheck returns in well under a second on typical projects — which is what makes this usable as an inner loop the agent runs between edits. When typecheck already targets another tool, leave it untouched and add typecheck:tsc alongside.

When a Setting "Isn't Working", Show the Resolved Config

npx tsc --showConfig

Prints the fully resolved config after all extends. The single most useful command when a setting "isn't working" — run it before guessing.

Merge Rules for an Existing tsconfig

When tsconfig.json already exists, do not overwrite. Surface the diff against the matching template above, flag any standing-policy violations (strict: false, skipLibCheck: false, trio mismatch), and let the user decide whether to migrate. Recommended migration order to minimize churn:

  1. strict: true
  2. noUnusedLocals + noUnusedParameters
  3. noImplicitReturns + noFallthroughCasesInSwitch
  4. noUncheckedIndexedAccess
  5. exactOptionalPropertyTypes
  6. verbatimModuleSyntax

Run npm run typecheck after each step. Commit between steps.

Verification

  • npx tsc --noEmit exits 0 on the project after the chosen template is applied (or surfaces real type errors that should be fixed).
  • npx tsc --showConfig prints a resolved config matching the standing policy.

References

  • TypeScript compiler options:
  • TypeScript modules guide:

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet, be the first.

Versions

  • v0.1.0 Imported from the upstream source.