/sota-javascript-typescript

name: sota-javascript-typescript
description: State-of-the-art JavaScript and TypeScript engineering (2026) for both writing and auditing code. Covers strict TypeScript configuration and type design, language idioms and pitfalls, async patterns, Node.js backends, JS/TS-specific security (XSS, prototype pollution, supply chain, injection), frontend/React and Node performance, and testing/tooling. Use whenever building, reviewing, refactoring, or security-auditing code involving JavaScript, TypeScript, Node, npm, React, frontend code, tsconfig, package.json, vitest, or any .ts/.tsx/.js/.mjs files.

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 = last JS-based compiler; 7.0 Go-native since July 2026, shipped as the regular `typescript` package **with no compiler API** — typescript-eslint, including the non-negotiable `no-floating-promises`, and Volar-based frameworks (Vue/Angular/Astro/Svelte) still need the 6.0 API, so install `typescript` as `npm:@typescript/typescript6` beside 7.0 until they support 7: [rules/01](rules/01-typescript-config-and-types.md)), ESM-first, Node LTS ≥22 (run the line marked Active LTS at github.com/nodejs/Release; 26 is scheduled for LTS on 2026-10-28 and ships Temporal by default), ES2024+ available, React 19.2-era with Server Components and React Compiler (stable since 1.0) where relevant, latest stable Vitest + flat-config ESLint (the default since v9).

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](rules/01-typescript-config-and-types.md)), 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](rules/07-testing-and-tooling.md)). 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)

**Coverage:** every `rules/` file's Audit checklist applies in AUDIT mode. Mark one *not applicable* only with its reason in the report — never skip a file because the thing it checks for is absent, since that absence may be the finding.

Scope first (frontend? Node service? library?), then read the matching rules files and run their audit checklists — each ends with grep/eslint hunt patterns. Validate findings: confirm attacker-controlled data actually reaches the sink, confirm the perf issue is on a hot path. No speculative findings.

**Severity conventions:**

• **CRITICAL** — remotely exploitable now: untrusted input reaching eval/exec/SQL, auth bypass, an XSS where script can read a session token or secret (one band up from HIGH, as [`sota-code-security`](../sota-code-security/SKILL.md) adjusts for context).
• **HIGH** — exploitable with conditions, or guaranteed-corruption bug class: untrusted HTML reaching `innerHTML`/`dangerouslySetInnerHTML` (stored or reflected XSS, [`sota-code-security`](../sota-code-security/SKILL.md)'s High band), missing boundary validation, prototype-pollution-prone merge of request data, floating promises dropping errors, tokens in localStorage, unbounded request bodies, float money math, sync crypto blocking the loop.
• **MEDIUM** — weakened posture or latent defect: missing strict tsconfig flags, no graceful shutdown, missing CSP/timeouts, `||` vs `??` on falsy-valid values, index keys on mutable lists, unbounded caches, missing supply-chain controls.
• **LOW** — hygiene/debt: dead deps, `hasOwnProperty`, console.log in services, snapshot sprawl, missing memoization on profiled-hot paths.

**Finding format:** Expands the router's canonical row (`file:line | rule | severity | effort | fix`, which wins on a cross-domain roll-up); evidence block and report order: [`sota` rules/03](../sota/rules/03-audit-findings.md) §2 and §5.

[SEVERITY] Title (CWE-xxx if security)
File: path/to/file.ts:42
Rule: rules/NN-name.md § section
Issue: what is wrong, in one or two sentences
Evidence: the offending snippet
Impact: what an attacker/user/operator experiences
Fix: concrete change (code if short)
Effort: trivial | small | medium | large

Order the report CRITICAL→LOW, deduplicate repeated patterns into one finding with a file list, and end with the top 3 systemic recommendations (e.g., "enable noUncheckedIndexedAccess", "adopt MSW", "add zod to route boundaries").

Rules index

| File | Read this when... | |---|---| | [rules/01-typescript-config-and-types.md](rules/01-typescript-config-and-types.md) | touching tsconfig (**TS ≥6.0 `types: []` / `rootDir` defaults; TS 7.0 has no compiler API — the `typescript6` alias for typed lint**; `.ts` import specifiers under Node type stripping); designing types/interfaces; seeing `any`/cast