SOTA JavaScript / TypeScript Engineering

Purpose

This skill encodes 2026 state-of-the-art for JS/TS so generated code is strict, secure, and fast by default — and so audits of existing code find the bug classes that actually bite: untyped boundaries, floating promises, XSS sinks, prototype pollution, supply-chain gaps, event-loop blocking, and leak-prone listeners. It has two operating modes; pick one explicitly at the start of a task.

Baseline assumptions (mid-2026): TypeScript ≥5.9 strict (6.0 is current and the last JS-based compiler; TS 7 "tsgo" native preview available), ESM-first, Node LTS ≥22 (24 = active LTS; Node 26 ships Temporal by default), ES2024+ available, React 19.2-era with Server Components and React Compiler 1.0 where relevant, vitest 4 + flat-config ESLint (v9/v10).

BUILD mode (writing or modifying code)

1. Read the relevant rules files first (index below) for the area you're touching. Don't generate from memory what a rules file specifies.
2. Defaults unless the codebase dictates otherwise: strict tsconfig (rules/01), ESM, unknown over any, discriminated unions for state, zod/valibot parse at every untrusted boundary, ??/?. discipline, AbortController on cancellable ops, pino logging in services, Web APIs over deps.
3. Match the host codebase for style, framework, and structure — but do not replicate its security bugs or any-sprawl into new code. New code meets the bar even in old repos.
4. Boundary rule: every input from outside the type system (HTTP, env, JSON.parse, storage, postMessage, DB without typed client) is parsed with a schema before use. No as T on external data.
5. Finish the job: new code compiles under tsc --noEmit, passes lint, and ships with behavior-level tests (rules/07). Handle the error path of every async call — no floating promises.
6. When a requirement conflicts with a rule (e.g., legacy CJS, jest), follow the codebase and note the deviation; don't silently half-apply both.

AUDIT mode (reviewing existing code)