You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello Vite team, thanks for maintaining this nice tool! I just found a bug so I would like to fix it
Description
When server.middlewareMode: true and appType: "custom", we can pass Node.js server instance to server.hmr.server option as well to make sure we use single port to serve everything (HTML, client script, and HMR WebSocket).
In this case, currently the HMR WebSocket client tries to connect to the hard-coded port (24678), which is not listened on by anything and simply causes connection error. Please try a repro here to reproduce the bug. (UPDATE: Now I included new playground & test case in this PR so you can use them instead as a repro)
In this PR, I propose to make sure to use importMetaUrl.port under this configuration so that the HMR WebSocket client can always connect to the server reliably in any case even under HTTP reverse proxy with WebSocket support, also under a firewall to allow only a single port (e.g. 8080 port for everything)
I now also added playground/custom-server-single-port to easily confirm the fixed behavior with a test case to verify established WebSocket connection with the correct target URL.
About the importance of this bug, this setup is quite useful when the dev server can be mounted in different environments including reverse proxies (assuming the reverse proxy can proxy WebSocket as well). Making sure multiple ports works fine with any environment is hard considering there can be many intermediate things including firewall / proxy config.
Additional context
I have several things I need help from reviewers.
Is the logic correct? I believe this is at least an improvement but not sure about all the edge cases
Is the added playground / test case reasonable? Is it fine to create the whole new playground for this specific case? (I think this case is important one though)
What is the purpose of this pull request?
Bug fix
New Feature
Documentation update
Other
Before submitting the PR, please make sure you do the following
Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
Ideally, include relevant tests that fail without this PR but pass with it.
Notes on the added test case in this PR
I confirmed that this added test case fails as expected on the current main branch (13ac37d) and it passes with this PR.
Here is the local test run log:
naruaway
changed the title
fix(hmr): importMetaUrl.port should be used when HMR server is provided
fix(hmr): HMR WS target inference should work with provided HMR server
Dec 26, 2022
naruaway
changed the title
fix(hmr): HMR WS target inference should work with provided HMR server
fix(hmr): hmr ws target inference should work with provided hmr server
Dec 26, 2022
naruaway
changed the title
fix(hmr): hmr ws target inference should work with provided hmr server
fix(hmr): custom middleware mode with server.hmr.server config causes HMR WebSocket failure
Dec 26, 2022
naruaway
changed the title
fix(hmr): custom middleware mode with server.hmr.server config causes HMR WebSocket failure
fix(hmr): custom middleware mode with server.hmr.server causes HMR WebSocket failure
Dec 26, 2022
naruaway
changed the title
fix(hmr): custom middleware mode with server.hmr.server causes HMR WebSocket failure
fix(hmr): hmr websocket failure for custom middleware mode with server.hmr.server
Dec 29, 2022
@sapphi-red, thanks for great suggestions!
After some thought now I think it's better to update the current middleware-mode example in vite-setup-catalogue. I really love this setup for various reasons. Could you check sapphi-red/vite-setup-catalogue#16?
Now I also removed playground related changes from this Vite PR in favor of the vite-setup-catalogue 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
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.
Hello Vite team, thanks for maintaining this nice tool! I just found a bug so I would like to fix it
Description
When
server.middlewareMode: trueandappType: "custom", we can pass Node.js server instance toserver.hmr.serveroption as well to make sure we use single port to serve everything (HTML, client script, and HMR WebSocket).In this case, currently the HMR WebSocket client tries to connect to the hard-coded port (
24678), which is not listened on by anything and simply causes connection error.Please try a repro here to reproduce the bug. (UPDATE: Now I included new playground & test case in this PR so you can use them instead as a repro)
In this PR, I propose to make sure to use
importMetaUrl.portunder this configuration so that the HMR WebSocket client can always connect to the server reliably in any case even under HTTP reverse proxy with WebSocket support, also under a firewall to allow only a single port (e.g.8080port for everything)I now also added
playground/custom-server-single-portto easily confirm the fixed behavior with a test case to verify established WebSocket connection with the correct target URL.About the importance of this bug, this setup is quite useful when the dev server can be mounted in different environments including reverse proxies (assuming the reverse proxy can proxy WebSocket as well). Making sure multiple ports works fine with any environment is hard considering there can be many intermediate things including firewall / proxy config.
Additional context
I have several things I need help from reviewers.
What is the purpose of this pull request?
Before submitting the PR, please make sure you do the following
fixes #123).Notes on the added test case in this PR
I confirmed that this added test case fails as expected on the current
mainbranch (13ac37d) and it passes with this PR.Here is the local test run log:
On
main(13ac37d)Test run output
This PR
Test run output