{"owner":"glideapps","repo":"quicktype","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["CLAUDE.md"],"skills":{"CLAUDE.md":"# Repository conventions\n\n## Environment\n\n- This is a TypeScript/npm monorepo using npm workspaces.\n- 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.\n- Install dependencies with `npm ci`.\n\n## Build and run\n\nBuild everything with:\n\n```bash\nnpm run build\n```\n\nThis runs `npm run clean`, builds all workspaces that have a `build` script, and then runs the root `tsc`.\n\nAfter building, the CLI entry point is `dist/index.js`:\n\n```bash\nnode dist/index.js --version\nnode dist/index.js --help\n```\n\nFor live rebuild/re-run while developing renderer output, use:\n\n```bash\nnpm start -- \"<quicktype args>\"\n```\n\n## Testing\n\n### Test strategy\n\nquicktype'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.\n\nAny 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.\n\n### Fixture layout and configuration\n\n- 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.\n- 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.\n- New schema fixture tests should have at least one positive and one negative test case unless there is a compelling reason not to.\n- Per-language configuration—input filters, renderer options, and `features`—lives in `test/languages.ts`.\n- Fixtures and their filter names are registered in `test/fixtures.ts`; driver programs live in `test/fixtures/<language>/`.\n\n### Test commands\n\nRun the standalone Vitest unit and regression tests with:\n\n```bash\nnpm run test:unit\nnpm run test:unit:watch\n```\n\nRun fixture tests with:\n\n```bash\nnpm run test:fixtures\n```\n\nUse fixture filters for focused local testing. Fixture names are registered in `test/fixtures.ts`; comma-separated groups are supported:\n\n```bash\nQUICKTEST=true FIXTURE=javascript npm run test:fixtures\nQUICKTEST=true FIXTURE=typescript npm run test:fixtures -- test/inputs/json/samples/pokedex.json\nFIXTURE=php npm run test:fixtures\nFIXTURE=schema-php npm run test:fixtures\nCPUs=2 QUICKTEST=true FIXTURE=javascript npm run test:fixtures\n```\n\n`QUICKTEST=true` skips the large miscellaneous JSON input set. Arguments after `--` select sample files or directories.\n\n`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`.\n\nFormatting and linting use Biome:\n\n```bash\nnpm run lint\nnpm run lint:fix\n```\n\n## Known CI flakiness\n\nThree fixture-CI failure modes are infrastructure flakes rather than test or PR bugs:\n\n- **scala3-upickle**: the Bloop compiler server sometimes times out after 30 seconds at startup, and `maven-nightlies` artifact downloads sometimes fail.\n- **elm**: fixture setup (`rm -rf elm-stuff && elm make Warmup.elm`) can race the compiler and deadlock on `elm-stuff/*.dat` file locks.\n- **cjson**: `cJSON.c` is downloaded from raw.githubusercontent.com at test time and can encounter transient SSL or connection failures.\n\nThe 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.\n\nFor 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.\n\n## Releasing and version bumps\n\nDo not bump versions in any `package.json` before a release. Package manifest versions are intentionally allowed to be stale in the repository.\n\nTo 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.\n\nBoth 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.\n\nTest the release-version helper with:\n\n```bash\nnpm run test:release\n```\n"},"files":{"CLAUDE.md":"# Repository conventions\n\n## Environment\n\n- This is a TypeScript/npm monorepo using npm workspaces.\n- 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.\n- Install dependencies with `npm ci`.\n\n## Build and run\n\nBuild everything with:\n\n```bash\nnpm run build\n```\n\nThis runs `npm run clean`, builds all workspaces that have a `build` script, and then runs the root `tsc`.\n\nAfter building, the CLI entry point is `dist/index.js`:\n\n```bash\nnode dist/index.js --version\nnode dist/index.js --help\n```\n\nFor live rebuild/re-run while developing renderer output, use:\n\n```bash\nnpm start -- \"<quicktype args>\"\n```\n\n## Testing\n\n### Test strategy\n\nquicktype'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.\n\nAny 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.\n\n### Fixture layout and configuration\n\n- 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.\n- 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.\n- New schema fixture tests should have at least one positive and one negative test case unless there is a compelling reason not to.\n- Per-language configuration—input filters, renderer options, and `features`—lives in `test/languages.ts`.\n- Fixtures and their filter names are registered in `test/fixtures.ts`; driver programs live in `test/fixtures/<language>/`.\n\n### Test commands\n\nRun the standalone Vitest unit and regression tests with:\n\n```bash\nnpm run test:unit\nnpm run test:unit:watch\n```\n\nRun fixture tests with:\n\n```bash\nnpm run test:fixtures\n```\n\nUse fixture filters for focused local testing. Fixture names are registered in `test/fixtures.ts`; comma-separated groups are supported:\n\n```bash\nQUICKTEST=true FIXTURE=javascript npm run test:fixtures\nQUICKTEST=true FIXTURE=typescript npm run test:fixtures -- test/inputs/json/samples/pokedex.json\nFIXTURE=php npm run test:fixtures\nFIXTURE=schema-php npm run test:fixtures\nCPUs=2 QUICKTEST=true FIXTURE=javascript npm run test:fixtures\n```\n\n`QUICKTEST=true` skips the large miscellaneous JSON input set. Arguments after `--` select sample files or directories.\n\n`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`.\n\nFormatting and linting use Biome:\n\n```bash\nnpm run lint\nnpm run lint:fix\n```\n\n## Known CI flakiness\n\nThree fixture-CI failure modes are infrastructure flakes rather than test or PR bugs:\n\n- **scala3-upickle**: the Bloop compiler server sometimes times out after 30 seconds at startup, and `maven-nightlies` artifact downloads sometimes fail.\n- **elm**: fixture setup (`rm -rf elm-stuff && elm make Warmup.elm`) can race the compiler and deadlock on `elm-stuff/*.dat` file locks.\n- **cjson**: `cJSON.c` is downloaded from raw.githubusercontent.com at test time and can encounter transient SSL or connection failures.\n\nThe 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.\n\nFor 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.\n\n## Releasing and version bumps\n\nDo not bump versions in any `package.json` before a release. Package manifest versions are intentionally allowed to be stale in the repository.\n\nTo 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.\n\nBoth 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.\n\nTest the release-version helper with:\n\n```bash\nnpm run test:release\n```\n"},"items":[{"name":"CLAUDE.md","path":"CLAUDE.md","title":"CLAUDE.md","content":"# Repository conventions\n\n## Environment\n\n- This is a TypeScript/npm monorepo using npm workspaces.\n- 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.\n- Install dependencies with `npm ci`.\n\n## Build and run\n\nBuild everything with:\n\n```bash\nnpm run build\n```\n\nThis runs `npm run clean`, builds all workspaces that have a `build` script, and then runs the root `tsc`.\n\nAfter building, the CLI entry point is `dist/index.js`:\n\n```bash\nnode dist/index.js --version\nnode dist/index.js --help\n```\n\nFor live rebuild/re-run while developing renderer output, use:\n\n```bash\nnpm start -- \"<quicktype args>\"\n```\n\n## Testing\n\n### Test strategy\n\nquicktype'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.\n\nAny 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.\n\n### Fixture layout and configuration\n\n- 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.\n- 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.\n- New schema fixture tests should have at least one positive and one negative test case unless there is a compelling reason not to.\n- Per-language configuration—input filters, renderer options, and `features`—lives in `test/languages.ts`.\n- Fixtures and their filter names are registered in `test/fixtures.ts`; driver programs live in `test/fixtures/<language>/`.\n\n### Test commands\n\nRun the standalone Vitest unit and regression tests with:\n\n```bash\nnpm run test:unit\nnpm run test:unit:watch\n```\n\nRun fixture tests with:\n\n```bash\nnpm run test:fixtures\n```\n\nUse fixture filters for focused local testing. Fixture names are registered in `test/fixtures.ts`; comma-separated groups are supported:\n\n```bash\nQUICKTEST=true FIXTURE=javascript npm run test:fixtures\nQUICKTEST=true FIXTURE=typescript npm run test:fixtures -- test/inputs/json/samples/pokedex.json\nFIXTURE=php npm run test:fixtures\nFIXTURE=schema-php npm run test:fixtures\nCPUs=2 QUICKTEST=true FIXTURE=javascript npm run test:fixtures\n```\n\n`QUICKTEST=true` skips the large miscellaneous JSON input set. Arguments after `--` select sample files or directories.\n\n`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`.\n\nFormatting and linting use Biome:\n\n```bash\nnpm run lint\nnpm run lint:fix\n```\n\n## Known CI flakiness\n\nThree fixture-CI failure modes are infrastructure flakes rather than test or PR bugs:\n\n- **scala3-upickle**: the Bloop compiler server sometimes times out after 30 seconds at startup, and `maven-nightlies` artifact downloads sometimes fail.\n- **elm**: fixture setup (`rm -rf elm-stuff && elm make Warmup.elm`) can race the compiler and deadlock on `elm-stuff/*.dat` file locks.\n- **cjson**: `cJSON.c` is downloaded from raw.githubusercontent.com at test time and can encounter transient SSL or connection failures.\n\nThe 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.\n\nFor 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.\n\n## Releasing and version bumps\n\nDo not bump versions in any `package.json` before a release. Package manifest versions are intentionally allowed to be stale in the repository.\n\nTo 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.\n\nBoth 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.\n\nTest the release-version helper with:\n\n```bash\nnpm run test:release\n```\n","category":"root","tokens":1458}]}