Run & review this pull request in StackBlitz Codeflow.

@SukkaW is attempting to deploy a commit to the Hey API Team on Vercel.

A member of the Team first needs to authorize it.

🦋 Changeset detected

Latest commit: 6e5249f

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

TL;DR — Broad performance sweep across the code generation pipeline: pre-computes serialized cache keys in the symbol registry, converts synchronous file I/O to parallel async writes, swaps the yaml parser for the faster js-yaml, and eliminates redundant loops and allocations in the graph walker, scope seeding, and declaration ordering. Also adds total elapsed time and file count to the CLI completion log.

Key changes

• Pre-compute serialized index entries in SymbolRegistry — stores the serialized form directly as IndexEntry[2] at creation time, removing repeated serializeIndexEntry calls; inlines registerCacheDependencies into the query method for a single combined pass
• Single-pass bucket sort in walkDeclarations — replaces the O(groups × pointers) pre-compute loop with a single pass that buckets pointers by group, using a Set for O(1) group membership checks
• Inline seedLocalScopes into the graph-building loop — avoids a second full pass over graph.nodes by merging scope seeding with the parentToChildren cache build; replaces the /properties/[^/]+$/ regex with lastIndexOf-based string checks
• Switch YAML parser from yaml to js-yaml — lighter dependency with faster parse times for the JSON Schema ref parser
• Convert synchronous file writes to parallel async — generateOutput now uses fsPromises with Promise.all for both openapi-ts and openapi-python
• Add file count and total elapsed time to CLI output — the "Done!" log now shows file count (with correct singular/plural) and wall-clock duration via @lukeed/ms

_{Summary ｜ 13 files ｜ 13 commits ｜ base: main ← improve-speed-2}

Pre-computed serialization and inlined cache registration in SymbolRegistry

Before: serializeIndexEntry called on every cache lookup, invalidation, and dependency registration; registerCacheDependencies was a separate method with its own loop
After: serialized string stored as IndexEntry[2] at creation time; registerCacheDependencies removed and its logic folded into the query method's existing loop

The IndexEntry tuple gains a third element (serialized: string) populated once in buildIndexKeySpace. All consumers now read indexEntry[2] instead of calling serializeIndexEntry. The _cacheDependencies map stores the full IndexKeySpace directly (instead of a pre-serialized string array), and the reverse-index registration in _dependencyToCache happens inline during the query loop — combining index-set building with dependency tracking in a single pass.

registry.ts

Single-pass bucket sort in walkDeclarations

Before: two separate loops — one to pre-compute each pointer's group via matchPointerToGroup, then a nested loop O(groups × pointers) to emit in group order
After: single pass buckets pointers into a Map<string, string[]> by group; preferred groups are checked via a Set for O(1) membership; emission iterates buckets in order then the unmatched remainder

The fallback path (no preferGroups) also avoids materializing an intermediate array by iterating graph.nodes entries directly.

walk.ts

Merged scope seeding with parentToChildren cache build

Before: seedLocalScopes iterated all graph.nodes in a separate pass after the parentToChildren cache loop
After: scope seeding logic inlined into the same for loop that builds parentToChildren, eliminating a second full traversal

The regex pointer.match(/\/properties\/[^/]+$/) is replaced with two lastIndexOf calls and a slice comparison. instanceof Array checks in buildGraph are also normalized to Array.isArray().

graph.ts

Parallel async file writes and elapsed time logging

Before: files written sequentially with fs.writeFileSync / fs.mkdirSync; no timing or file count in CLI output
After: files written in parallel via fsPromises.mkdir + fsPromises.writeFile with Promise.all; CLI logs total file count and wall-clock duration with correct singular/plural handling

Both openapi-ts and openapi-python output generators now collect write promises and flush them concurrently. The generateOutput return type changes from Promise<void> to Promise<{ fileCount: number }>, and createClient captures total elapsed time via Date.now() to produce the new log line:

✅ Done! Your output is in ./output (42 files in 1.2s)

The @lukeed/ms package is added as a dependency to both openapi-ts and openapi-python for human-readable duration formatting. A changeset is included for the @hey-api/openapi-ts package.

output.ts (ts) · output.ts (py) · createClient.ts (ts) · createClient.ts (py)

yaml → js-yaml in JSON Schema ref parser

Before: yaml package (heavier, spec-complete YAML 1.2 parser)
After: js-yaml (lighter, faster YAML parser sufficient for OpenAPI specs)

A straightforward dependency swap — parse from yaml replaced with load from js-yaml.

yaml.ts · package.json

  ^{｜ View workflow run ｜ via Pullfrog ｜ 𝕏}

Acknowledged the author's response on the parseStart placement comment — no code changes needed. The author is aware the timing includes I/O and considers it acceptable for now.

  ^{｜ View workflow run ｜ via Pullfrog ｜ 𝕏}

Acknowledged the author's reasoning on the "render" label — no code change needed. The label aptly distinguishes the in-memory output generation phase from the disk-write phase.

  ^{｜ View workflow run ｜ via Pullfrog ｜ 𝕏}

Acknowledged the author's note that 46a033d makes the "render" label discussion moot. Replied and resolved the thread — no code changes needed.

  ^{｜ View workflow run ｜ via Pullfrog ｜ 𝕏}

No code changes needed — the parseStart placement concern was already addressed by the author in 46a033d. Replied and resolved the thread.

  ^{｜ View workflow run ｜ via Pullfrog ｜ 𝕏}

Acknowledged the author's reply — the mkdir optimization suggestion was already marked as non-blocking, and the author confirmed the total write time is negligible. No code changes needed.

  ^{｜ View workflow run ｜ via Pullfrog ｜ 𝕏}

Reviewed PR #3828 — no blocking issues found. All performance optimizations (iterative DFS, pre-computed index serialization, single-pass walk bucketing, yaml → js-yaml swap, concurrent async writes) are correct. Review posted.

  ^{｜ View workflow run ｜ via Pullfrog ｜ 𝕏}

Codecov Report

❌ Patch coverage is 86.20690% with 12 lines in your changes missing coverage. Please review.
✅ Project coverage is 39.59%. Comparing base (460e71c) to head (6e5249f).
⚠️ Report is 14 commits behind head on main.

@@            Coverage Diff             @@
##             main    #3828      +/-   ##
==========================================
+ Coverage   39.57%   39.59%   +0.02%     
==========================================
  Files         532      532              
  Lines       19544    19561      +17     
  Branches     5817     5825       +8     
==========================================
+ Hits         7734     7746      +12     
- Misses       9568     9573       +5     
  Partials     2242     2242              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Open in StackBlitz

npm i https://pkg.pr.new/@hey-api/codegen-core@3828

npm i https://pkg.pr.new/@hey-api/json-schema-ref-parser@3828

npm i https://pkg.pr.new/@hey-api/nuxt@3828

npm i https://pkg.pr.new/@hey-api/openapi-ts@3828

npm i https://pkg.pr.new/@hey-api/shared@3828

npm i https://pkg.pr.new/@hey-api/spec-types@3828

npm i https://pkg.pr.new/@hey-api/types@3828

npm i https://pkg.pr.new/@hey-api/vite-plugin@3828

commit: 6e5249f

@pullfrog how do you feel about the pull request now? Is everything resolved?

Yes — everything from my reviews is resolved. All four threads from the initial review were addressed (two via 46a033d, two accepted as-is with good rationale), and the incremental re-review found no new issues. The PR looks good to merge from my side.

  ^{｜ View workflow run ｜ via Pullfrog ｜ 𝕏}