fix: auto generate types faster and more reliably to avoid issues when spawning processes #11315
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #11276
Previously, to auto generate types on HMR and startup we spawned a child process with the
payload generate:typescommand.This, potentially can cause some issues in monorepos (our Astro and Remix examples, as described in #11276) and whenever payload config path cannot be determined (as it's necessary for
payload.bin) It's also faster to executegenerateTypesdirectly.Nevertheless, it was a necessary change because of a turbopack issue #6714 vercel/next.js#66723
The issue now looks resolved, I tested against the latest next.js canary with a packed
payloadversion from this PR and types auto-generation works correctly usingpnpm dev --turbo.Other changes were necessary to pass integration and unit tests Apparently, as
jestisn't executed in a proper ESM environment, it requires to use--experimental-vm-modulesto be able to loadjson-schema-to-typescript.