fix(schema-input): decode percent-encoded JSON Pointer segments in $ref

[schani]

The bug

quicktype -s typescript -l c++ ... (and -l typescript) fatally errors on
generic classes instantiated with more than one type argument, e.g.:

export class StateInfo<T> {
    public state: T;
    public changeTime: number;
}
export enum xxx { jam = "xx", jest = "yy" }
export enum www { Disabled = "asd", Ok = "qwe" }
export class foo { public state: StateInfo<xxx>; }
export class woo { public test2: StateInfo<www>; }

Error: Key StateInfo%3CT%3E not in schema object at /#StateInfo%3CT%3E.

No output files are produced at all. This is a regression from the original
report in #1992, where instead of erroring, quicktype silently misnamed the
first generic instantiation's enum (PurpleStateInfoT) — same root cause,
different (now worse) symptom.

Root cause

quicktype-typescript-input converts TypeScript generics into monomorphized
JSON Schema definitions, e.g. a definition literally named "StateInfo<T>",
referenced via "$ref": "#/definitions/StateInfo%3CT%3E" (URI-fragment
percent-encoded, since </> aren't valid in a bare JSON Pointer/URI
fragment).

quicktype-core's Ref.parsePath (in
packages/quicktype-core/src/input/JSONSchemaInput.ts), which turns a $ref
fragment into path segments for definition lookup, split the fragment on /
but never percent-decoded the segments. So it looked up the literal key
"StateInfo%3CT%3E" in schema.definitions, which doesn't exist (the real
key is "StateInfo<T>"), and failed with SchemaKeyNotInObject. Per RFC 6901
§6, a URI fragment used as a JSON Pointer must be percent-decoded before its
segments are interpreted — that step was missing.

Separately, schemaForTypeScriptSources in
packages/quicktype-typescript-input/src/index.ts built top-level $ref
URIs without percent-encoding special characters in the name, and its
fallback for selecting "top-level" types (when no #TopLevel marker is
present) picked up internal helper definitions rather than the program's
actual exported symbols — this fallback path is what produced the original
PurpleStateInfoT misnaming.

The fix

• Ref.parsePath: percent-decode each /-separated path segment after
  splitting (so StateInfo%3CT%3E resolves to the real StateInfo<T> key).
• schemaForTypeScriptSources: percent-encode generated top-level definition
  URIs to stay consistent with how $refs are encoded elsewhere, and use
  generator.getMainFileSymbols() (the program's actual exported symbols) as
  the top-level type set instead of arbitrary internal definitions when no
  #TopLevel marker is present.

Test coverage

• test/inputs/schema/percent-encoded-ref.schema (+ .1.json sample): a new
  JSON Schema fixture whose $refs use percent-encoded characters (<, >)
  in the JSON Pointer, directly exercising Ref.parsePath. Fails against
  unfixed code with the same SchemaKeyNotInObject error; passes after the
  fix. Runs automatically for every schema-<language> fixture (verified
  locally for schema-typescript and schema-cplusplus).
• test/unit/typescript-input.test.ts: new regression test
  ("generic instantiations retain their exported type names") reproducing
  the exact ts to C++ class template argument renamed #1992 repro end-to-end through quicktype() with the
  TypeScript-source input, asserting the two monomorphized classes get
  distinct correct names (StateInfoXxx, StateInfoWWW) and that neither
  PurpleStateInfoT nor StateInfoT1 appear.

Verification performed locally

• npm run build passes.
• npm run test:unit: 164/164 tests pass (25 files).
• QUICKTEST=true FIXTURE=schema-typescript script/test test/inputs/schema/percent-encoded-ref.schema passes.
• QUICKTEST=true FIXTURE=schema-cplusplus script/test test/inputs/schema/percent-encoded-ref.schema passes (compiled and ran with g++/nlohmann-json).
• Re-ran the exact issue repro (-s typescript -l c++ ... with the sample
  from ts to C++ class template argument renamed #1992, both in original and reversed class-declaration order):
  previously fatal, now generates StateInfoXxx.hpp / StateInfoWww.hpp
  (and the TypeScript-language equivalent) with correct, order-independent
  names and no PurpleStateInfoT/collision renaming.
• Confirmed an unrelated, pre-existing failure in the full schema-typescript
  fixture run (test/inputs/schema/vega-lite.schema fails to compile with
  tsc due to an unrelated index-signature type conflict) reproduces
  identically on unmodified master, so it is not caused by this change; CI
  will cover the rest of the fixture matrix.

Fixes #1992.

🤖 Generated with Claude Code

[github-actions]

Generated-output differences

40 files differ — 0 modified, 40 new, 0 deleted
3998 changed lines — +3998 / −0

Open the generated-output report →