Module typescript 

Turning TypeScript rule modules into JavaScript the engine can run.

Blanking, not rewriting

Type syntax is overwritten with spaces in place rather than removed. Every byte that survives keeps its original offset, and newlines inside a blanked range are preserved, so a line and column in the generated JavaScript is the same line and column in the author’s TypeScript.

That is the whole reason for this approach. A stack trace from a rule that threw points at the author’s source directly, with no source map to generate, ship, parse or get subtly wrong. For a tool whose value rests on the quality of what it tells you when something is wrong, that is worth more than it costs.

The alternative was a full TypeScript transformer, which would handle every construct but add roughly eighty crates to a dependency graph that is currently thirty-six — on a tool that runs as a pre-commit hook and is therefore a supply-chain target. See docs/architecture.md §13.

What is not supported

Blanking works only for syntax that has no runtime meaning. Four TypeScript features generate code, so there is nothing to blank and they are rejected with an explanation: enum, namespace, decorators, and constructor parameter properties.

Rule modules are small and self-contained, and each of these has a plain alternative. Rejecting loudly is much better than emitting JavaScript that silently means something else.

The safety net

Stripping is verified rather than trusted: the result is parsed as JavaScript, and a syntax error means the stripper is wrong, not the author. That check turns a whole class of subtle stripping bugs into a loud failure at the point of the mistake.

Enums

StripError

Why a rule module could not be prepared for execution.

Unsupported

A TypeScript construct that cannot be stripped.

Functions

strip_types

Strip TypeScript type syntax, returning JavaScript with identical byte offsets.