[pull] master from glideapps:master

.github/ISSUE_TEMPLATE/bug_report.md

@@ -1,7 +1,7 @@
 ---
-name: New Bug Report
-about: Use this template for reporting new bugs.
-title: "[BUG]: bug description here"
+name: Bug report
+about: Report a reproducible problem with quicktype
+title: "[BUG]: "
 labels: bug
 ---
 

.github/ISSUE_TEMPLATE/config.yml

@@ -1,5 +1 @@
 blank_issues_enabled: false
-# contact_links:
-#   - name: GitHub Community Support
-#     url: https://github.com/orgs/community/discussions
-#     about: Please ask and answer questions here.

.github/ISSUE_TEMPLATE/question.md

@@ -0,0 +1,13 @@
+---
+name: Question
+about: Ask a question about using quicktype
+title: "[QUESTION]: "
+---
+
+## Question
+
+<!-- What would you like to know? -->
+
+## Context
+
+<!-- Include relevant input, output, commands, and environment details. -->

.github/pull_request_template.md

@@ -4,9 +4,8 @@
 
 ## Related Issue
 
-<!--- If suggesting a new feature or change, please discuss it in an issue first -->
-<!--- If fixing a bug, there should be an issue describing it with steps to reproduce -->
-<!--- Please link to the issue here: -->
+<!--- Feature requests should be submitted as pull requests, not issues. -->
+<!--- If fixing a reported bug, please link to the issue here: -->
 
 ## Motivation and Context
 

AGENTS.md

@@ -0,0 +1 @@
+CLAUDE.md

CLAUDE.md

@@ -1,69 +1,108 @@
 # Repository conventions
 
+## Environment
+
+- This is a TypeScript/npm monorepo using npm workspaces.
+- Prefer the Node version from `.nvmrc` (`nvm use`; currently Node 24.6.0). The root CLI package requires Node >= 20.19.0; the library workspaces require Node >= 20.0.0.
+- Install dependencies with `npm ci`.
+
+## Build and run
+
+Build everything with:
+
+```bash
+npm run build
+```
+
+This runs `npm run clean`, builds all workspaces that have a `build` script, and then runs the root `tsc`.
+
+After building, the CLI entry point is `dist/index.js`:
+
+```bash
+node dist/index.js --version
+node dist/index.js --help
+```
+
+For live rebuild/re-run while developing renderer output, use:
+
+```bash
+npm start -- "<quicktype args>"
+```
+
 ## Testing
 
-quicktype's primary testing method is end-to-end fixture tests driven by JSON
-and JSON Schema files. For each sample input, the fixture generates code for a
-language, runs a driver program in `test/fixtures/<language>/` that
-deserializes the sample and serializes it back, and compares the round-tripped
-JSON to the input.
-
-- JSON inputs live in `test/inputs/json/`: `priority/` and `samples/` always
-  run, `misc/` is skipped under `QUICKTEST` (and for languages with
-  `skipMiscJSON`).
-- JSON Schema inputs live in `test/inputs/schema/`: each `*.schema` comes with
-  `.N.json` samples and `.N.fail.<feature>.json` expected-failure samples. A
-  fail sample must make the generated program exit nonzero; which fail
-  samples run is controlled by the language's `features` list.
-- Every schema fixture test must have at least one positive (`.N.json`) and
-  one negative (`.N.fail.<feature>.json`) test case, unless there is a very
-  good reason not to.
-- Per-language configuration — which inputs run (`skipJSON`, `includeJSON`,
-  `skipSchema`), renderer options, and `features` — lives in
-  `test/languages.ts`; fixtures are registered in `test/fixtures.ts`.
-- Run one language's fixtures with `FIXTURE=<name> script/test`, for example
-  `FIXTURE=php script/test` or `FIXTURE=schema-php script/test`.
-
-Any change that affects generated output MUST be covered by a JSON or JSON
-Schema fixture test — by enabling existing inputs for the language or adding
-new ones. Unit tests in `test/unit/` are a complement for what fixtures cannot
-express (asserting that some code is *not* generated, API-level behavior, fast
-local iteration) — never a substitute. Do not add a unit test when a fixture
-test will do the job: if a fixture input already exercises the behavior, a
-unit test duplicating that coverage is superfluous and should not be added.
+### Test strategy
+
+quicktype's primary testing method is end-to-end fixture tests driven by JSON and JSON Schema files. For each sample input, a fixture generates code for a language, runs a driver program in `test/fixtures/<language>/` that deserializes the sample and serializes it back, and compares the round-tripped JSON to the input.
+
+Any change that affects generated output **must** be covered by a JSON or JSON Schema fixture test, either by enabling existing inputs for the language or by adding new ones. Unit tests in `test/unit/` complement fixtures for behavior that fixtures cannot express, such as asserting that code is not generated, API-level behavior, or fast local iteration. Do not add a unit test when a fixture test already covers the behavior.
+
+### Fixture layout and configuration
+
+- JSON inputs live in `test/inputs/json/`. `priority/` and `samples/` form the default input set; `misc/` is omitted under `QUICKTEST` and for languages with `skipMiscJSON`. Per-language `skipJSON` and `includeJSON` settings can further restrict inputs.
+- JSON Schema inputs live in `test/inputs/schema/`. A `*.schema` can have a same-basename `.json` sample and numbered `.N.json` samples. Numbered `.N.fail.<feature>.json` files are expected failures for languages that declare that feature; `.N.fail.json` files apply regardless of features. An expected-failure sample must make the generated program exit nonzero.
+- New schema fixture tests should have at least one positive and one negative test case unless there is a compelling reason not to.
+- Per-language configuration—input filters, renderer options, and `features`—lives in `test/languages.ts`.
+- Fixtures and their filter names are registered in `test/fixtures.ts`; driver programs live in `test/fixtures/<language>/`.
+
+### Test commands
+
+Run the standalone Vitest unit and regression tests with:
+
+```bash
+npm run test:unit
+npm run test:unit:watch
+```
+
+Run fixture tests with:
+
+```bash
+npm run test:fixtures
+```
+
+Use fixture filters for focused local testing. Fixture names are registered in `test/fixtures.ts`; comma-separated groups are supported:
+
+```bash
+QUICKTEST=true FIXTURE=javascript npm run test:fixtures
+QUICKTEST=true FIXTURE=typescript npm run test:fixtures -- test/inputs/json/samples/pokedex.json
+FIXTURE=php npm run test:fixtures
+FIXTURE=schema-php npm run test:fixtures
+CPUs=2 QUICKTEST=true FIXTURE=javascript npm run test:fixtures
+```
+
+`QUICKTEST=true` skips the large miscellaneous JSON input set. Arguments after `--` select sample files or directories.
+
+`npm test` runs the Vitest suite followed by all fixture tests. The full fixture suite requires external language toolchains such as .NET, Java/Maven, Go, Rust, Python/mypy, PHP, Ruby, Kotlin, Scala, and Elixir; it will fail when a required toolchain is unavailable. GitHub Actions uses focused fixture groups configured in `.github/workflows/test-pr.yaml`, for example `QUICKTEST=true FIXTURE=${{ matrix.fixture }} npm run test:fixtures`.
+
+Formatting and linting use Biome:
+
+```bash
+npm run lint
+npm run lint:fix
+```
 
 ## Known CI flakiness
 
-Three fixture-CI failure modes are infrastructure flakes, not test or PR bugs:
+Three fixture-CI failure modes are infrastructure flakes rather than test or PR bugs:
+
+- **scala3-upickle**: the Bloop compiler server sometimes times out after 30 seconds at startup, and `maven-nightlies` artifact downloads sometimes fail.
+- **elm**: fixture setup (`rm -rf elm-stuff && elm make Warmup.elm`) can race the compiler and deadlock on `elm-stuff/*.dat` file locks.
+- **cjson**: `cJSON.c` is downloaded from raw.githubusercontent.com at test time and can encounter transient SSL or connection failures.
+
+The fixture matrix uses `fail-fast: true`, so one flaky job cancels sibling language jobs. The `test-complete` check only mirrors the matrix and is not an independent failure.
 
-- **scala3-upickle**: the Bloop compiler server sometimes times out after 30
-  seconds at startup, and `maven-nightlies` artifact downloads sometimes fail.
-- **elm**: the fixture setup (`rm -rf elm-stuff && elm make Warmup.elm`) can
-  race the compiler, deadlocking on `elm-stuff/*.dat` file locks.
-- **cjson**: `cJSON.c` is downloaded from raw.githubusercontent.com at test
-  time and can hit transient SSL/connection failures.
+For now, retry these failed jobs with `gh run rerun <run-id> --failed`. Treat a failure in one of these areas as real only if it reproduces across retries or the PR touches that area.
 
-Two things amplify them: the fixture matrix runs with `fail-fast: true`, so
-one flaky job cancels all sibling language jobs, and the `test-complete`
-check only mirrors the matrix — it is never an independent failure.
+## Releasing and version bumps
 
-For the time being we accept these flakes; when one happens, retry the failed
-jobs (`gh run rerun <run-id> --failed`). A failure in one of these areas only
-counts as real if it reproduces across retries or the PR actually touches
-that area.
+Do not bump versions in any `package.json` before a release. Package manifest versions are intentionally allowed to be stale in the repository.
 
-## Releasing / version bumps
+To publish, create a GitHub Release targeting the commit to release. Stable tags have the form `vMAJOR.MINOR.PATCH` (for example, `v24.0.0`); prerelease tags have the form `vMAJOR.MINOR.PATCH-preN` (for example, `v25.0.0-pre1`). Publishing the release triggers the npm workflow, which publishes stable versions under the `latest` dist-tag and prereleases under `pre`. The VS Code Marketplace workflow runs only for stable tags.
 
-Do not bump versions in any `package.json` before a release. Package manifest
-versions are intentionally allowed to be stale in the repository.
+Both workflows derive the version exclusively from the release tag and stamp all manifests in the Actions checkout before publishing; those changes are not committed. The release version must be greater than every earlier non-draft GitHub Release with a supported tag. Publication is refused if npm or the VS Code Marketplace already has a newer supported version; an exact version match is skipped, so rerunning a partially completed release is safe.
 
-To publish, create a stable GitHub Release targeting the commit to release and
-give it a tag in the form `vMAJOR.MINOR.PATCH`, for example `v24.0.0`. Publishing
-the release triggers the npm and VS Code Marketplace workflows. They derive the
-version exclusively from the release tag and stamp all manifests in the Actions
-checkout before publishing; those changes are not committed.
+Test the release-version helper with:
 
-The release version must be greater than every previous stable GitHub Release
-and every version already published for the npm packages and VS Code extension.
-Rerunning a partially completed release is safe: packages already published at
-the exact release version are skipped.
+```bash
+npm run test:release
+```

CONTRIBUTING.md

@@ -0,0 +1,7 @@
+# Contributing
+
+We do not accept feature requests as GitHub issues. If you want to add or change functionality, please submit a pull request instead.
+
+Use the provided issue templates for bug reports and questions.
+
+The use of coding agents is encouraged, but please use an Opus-class model or stronger rather than a lower-capability model. Review and test all generated changes before submitting them.

packages/quicktype-core/src/MakeTransformations.ts

@@ -80,8 +80,7 @@ function makeEnumTransformer(
     stringType: TypeRef,
     continuation?: Transformer,
 ): Transformer {
-    const sortedCases = Array.from(enumType.cases).sort();
-    const caseTransformers = sortedCases.map(
+    const caseTransformers = Array.from(enumType.cases).map(
         (c) =>
             new StringMatchTransformer(
                 graph,