fix(import-map): make the JSONC comment stripper honor string literals

[edunovaes]

Fixes #629

Problem

parseTsConfigText in extract-import-map.mjs strips JSONC comments with a regex that does not honor string literals. The code comments acknowledge this ("The strip is naive (it doesn't honor string contents), so we fall back to the raw text on failure"), but the raw-text fallback does not actually save the case that matters — because a tsconfig with comments is exactly the one that fails a raw JSON.parse.

tsconfig path aliases and include globs legitimately contain the comment delimiters:

{
  "compilerOptions": {
    // any comment at all
    "paths": { "@/*": ["./src/*"] }
  },
  "include": ["**/*.ts"]
}

The /* inside "@/*" opens a spurious block comment, and the */ inside "**/*.ts" closes it. Everything between the two is deleted:

"paths": {
      "@*.ts"]
}

So the stripped parse fails, the raw parse fails (real comments), parseTsConfigText returns null, and every alias from that tsconfig is dropped. The only signal is one stderr line:

Warning: extract-import-map: tsconfig.json at <path> failed to parse
 — path aliases from this config will not be applied — relative imports unaffected

The import map then silently contains only relative imports. Nothing downstream distinguishes "this project has few aliases" from "we threw all of them away".

Trigger conditions

Both must hold, and both are ordinary:

1. the tsconfig has any // or /* */ comment, and
2. it has a paths alias with a * and an include/exclude glob ("**/*.ts" is the create-next-app default).

Real-world impact

Measured on a Next.js project whose tsconfig.json carried a three-line // comment explaining an allowImportingTsExtensions decision, alongside the stock "@/*": ["./src/*"] and "include": ["**/*.ts", "**/*.tsx"]:

	files with imports	import edges
before	19	39
after	44	103

64 of 103 import edges — 62% of the project's import graph — were being discarded. Every one of the 66 @/… imports in the source resolved to nothing.

Fix

Replace the regex with a character scanner that tracks string/escape state, so delimiters inside string literals are left alone. Newlines inside block comments are preserved, keeping parse-error line numbers pointing at the original file. The raw-text parse remains as the fallback.

No signature change, no new dependency, no behavioural change for a tsconfig that already parsed.

Tests

Adds three cases to tests/skill/understand/test_extract_import_map.test.mjs. They are written as literal text rather than JSON.stringify, which is why the existing tsconfig tests never caught this — every one of them constructs comment-free JSON.

Case	tsconfig	Expected
line comment + globs	// comment next to "@/*" and "**/*.ts"	alias resolves, no parse warning
block comment + globs	multi-line /* */	alias resolves
// inside a string	"$schema": "https://json.schemastore.org/tsconfig"	value survives the stripper

The third is a guard on the fix itself rather than a reproduction — the old code passed it too, because a URL alone does not break the raw-text fallback.

Verified against the shipped script with a working runtime, comparing the old stripper to the new one with everything else held constant:

Case	old stripper	new stripper
line comment + globs	no resolution, failed to parse warning	resolves, no warning
block comment + globs	no resolution, failed to parse warning	resolves, no warning
// inside a string	resolves	resolves
plain JSON, no comments (regression)	resolves	resolves

Note

This is independent of the leading-./ alias fix (#214) already on main — that one is about the candidate path, this one is about the config never being parsed in the first place. A project hitting both saw its import edges go from 39 to 103 only after each was addressed.