fix(tanstack-start): HMR with payload config changes in dev - #17602
Open
r1tsuu wants to merge 1 commit into
Open
fix(tanstack-start): HMR with payload config changes in dev#17602r1tsuu wants to merge 1 commit into
r1tsuu wants to merge 1 commit into
Conversation
Editing payload.config.ts, or anything it imports, had no effect until a manual restart and logged nothing. Vite did re-evaluate the module, but getPayload returns its cached instance unless a DevReloadStrategy marks it stale, and endpoint routing reads payload.config off that stale instance. From there down this behaves exactly like Next.js: mark the instance stale, then let the next getPayload call swap in the new config, regenerate the import map and re-init the db. Only the signal and its delivery differ. Next.js gets that signal from defaultNextJsDevReloadStrategy, a websocket to /_next/webpack-hmr watching for serverComponentChanges. Nothing serves that path under Vite, so the connect failed and ws.onerror swallowed it, which is where the silence came from. It is also coarse: any server component change reloads Payload. The Vite plugin instead uses the hotUpdate plugin hook, in-process and socketless, and walks the changed module's importers so only edits that actually reach the config trigger a reload. Delivery differs because Next.js needs none. Its strategy is core's built-in default, so it already covers the getPayload calls made inside handleEndpoints and createPayloadRequest, which never see InitOptions. An adapter has no such fallback, so core gains a globalThis-backed strategy registry to give the plugin that same reach.
Contributor
|
Pull Request titles must follow the Conventional Commits specification and have valid scopes. The subject "HMR with payload config changes in dev" found in the pull request title "fix(tanstack-start): HMR with payload config changes in dev" |
Contributor
📦 esbuild Bundle Analysis for payloadThis analysis was generated by esbuild-bundle-analyzer. 🤖
Largest pathsThese visualization shows top 20 largest paths in the bundle.Meta file: packages/next/meta_index.json, Out file: esbuild/index.js
Meta file: packages/payload/meta_index.json, Out file: esbuild/index.js
Meta file: packages/payload/meta_shared.json, Out file: esbuild/exports/shared.js
Meta file: packages/richtext-lexical/meta_client.json, Out file: esbuild/exports/client_optimized/index.js
Meta file: packages/ui/meta_client.json, Out file: esbuild/exports/client_optimized/index.js
Meta file: packages/ui/meta_shared.json, Out file: esbuild/exports/shared_optimized/index.js
DetailsNext to the size is how much the size has increased or decreased compared with the base branch of this PR.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Editing payload.config.ts, or anything it imports, had no effect until a manual restart and logged nothing. Vite did re-evaluate the module, but getPayload returns its cached instance unless a DevReloadStrategy marks it stale, and endpoint routing reads payload.config off that stale instance.
From there down this behaves exactly like Next.js: mark the instance stale, then let the next getPayload call swap in the new config, regenerate the import map and re-init the db. Only the signal and its delivery differ.
Next.js gets that signal from defaultNextJsDevReloadStrategy, a websocket to /_next/webpack-hmr watching for serverComponentChanges. Nothing serves that path under Vite, so the connect failed and ws.onerror swallowed it, which is where the silence came from. It is also coarse: any server component change reloads Payload. The Vite plugin instead uses the hotUpdate plugin hook, in-process and socketless, and walks the changed module's importers so only edits that actually reach the config trigger a reload.
Delivery differs because Next.js needs none. Its strategy is core's built-in default, so it already covers the getPayload calls made inside handleEndpoints and createPayloadRequest, which never see InitOptions. An adapter has no such fallback, so core gains a globalThis-backed strategy registry to give the plugin that same reach.