generate-types + TSX (JSX) issue

[knightedcodemonkey]

Running knighted-css-generate-types --root . fails when it hits JSX. The CLI feeds each source file directly into es-module-lexer.parse(), which only understands standard JavaScript module syntax, so raw TSX causes a parse error before ?knighted-css&types imports are discovered.

Potential fixes

1. Inline transpile before parsing – Run files through a lightweight transformer (esbuild, sucrase, @swc/core) to strip TypeScript/JSX down to JS, then hand the result to parse().
2. Use typescript.transpileModule() – Invoke the TS compiler with { module: ESNext, jsx: ReactJSX, target: ES2022 } to emit JS (React.createElement) while preserving import specifiers.
3. Expose a lexer override hook – Promote the internal setLexerOverrides() helper so consumers can provide a JSX-capable parser (e.g., acorn + acorn-jsx), falling back to es-module-lexer for plain JS.
4. Heuristic retry – Wrap parse() in try/catch; if a .tsx/.jsx file fails, run a minimal JSX-stripping pass and retry to avoid new dependencies for vanilla projects.

The goal is to pick one (or combine several) so @knighted/css can parse JSX-heavy codebases without extra setup.

For now a workaround is to use @knighted/jsx to write JSX syntax within tagged template literals.

[knightedcodemonkey]

1. The Most Likely Winner: Heuristic "Lite" Transpilation
   Using a "Heuristic retry" with a tool like Sucrase or esbuild is the industry-standard approach for this.
   Why: Sucrase is designed specifically for this use case—it is extremely fast because it doesn't do type-checking; it just "erases" JSX and TS.
   The Workflow:
   Try parse().
   If it fails with a syntax error, run the file through a "JSX-to-JS" transform (preserving imports).
   Re-parse.
2. The "Zero-Dependency" Path: Heuristic Regex (Not recommended)
   Could try to regex-out the JSX, but JSX can be incredibly complex (nested tags, attributes with objects, etc.). This usually leads to more bugs than it solves.
3. The "Unified" Path: Acorn + Acorn-JSX
   Since OXC is already in use, the most consistent fix would actually be to use oxc-parser as the fallback lexer.
   Why: @knighted/jsx already uses it as a dependency. It is written in Rust and is faster than almost any other JS-based parser.
   Implementation: If es-module-lexer fails, hand the source to oxc-parser to walk the imports.
   The current workaround is actually a "Feature".
   Using @knighted/jsx tagged templates as a workaround is actually very clean. By putting JSX in strings:
   Lexing succeeds: es-module-lexer sees a string and skips it.
   No Build Step: Maintain the "no-transpile" Node.js workflow.
   Portability: The files remain valid ESM according to the spec.

Verdict for the CLI: If knighted-css-generate-types is to be a "universal" tool, option 3 (OXC Fallback). Since the @Knighted ecosystem already relies on OXC for the JSX transformation, it's the most efficient way to ensure the type generator can "see through" JSX without adding a massive new dependency like typescript or babel to the CLI.