Nuxi 3.7.x HMR doesn't work correctly in dev mode on WSL2
Closed this issue · 8 comments
Description
When using any nuxi version between 3.7.0 and 3.8.3, the behaviour seems subpar or erratic, degrading the DX. This has been detected, so far, in WSL2 environments.
Relevant notes:
- This affects blank projects as well as existing upgraded projects.
- It seems to display different behavior on different OS's
- Behavior is present on Windows 11 on WSL2 (Ubuntu 20, node 20 via nvm)
- Behavior is not present on Windows 11 natively (node 20 via nvm-windows)
- [Further investigation required for native Linux OS]
- [Further investigation required for Mac OS]
- When the issue is present, it also behaves differently whether its called by 127.0.0.1:[port] or localhost:[port]. Differences are listed below.
- The issue is not present when using nuxi version 3.6.5 (even with Nuxt 3.7.3) in any OS
Tests below where performed on blank projects.
Replication
- Create a blank project using
npx nuxi@3.8.3 init - Run it with
npx nuxi@3.8.3 dev - Open
http://127.0.0.1:3000on a browser - Open
http://localhost:3000on a browser
Environment
WSL2 running Ubuntu 20.04
Node 20, via nvm (also tested with node 18)
Behaviour accessing 127.0.0.1
When loading http://127.0.0.1:3000, the SSR is as fast as usual (in my system under 200ms), loading all the content and files necessary. However, after hydration, looks like the "_nuxt/" websocket connections closes, thus stopping the HMR cycle.
I've also noticed that the first call is the "_nuxt/" websocket, but after stopping, the subsequent failing HMR calls are regular fetch calls, instead of websockets (but I may be wrong).
Key points:
- SSR and content loading is correct and fast
- After hydration, websocket connection is refused and fails (subsequent websocket attempts seem to have the wrong protocol?)
- HMR is broken. Pages need to be fully refreshed for any changes
- Network is not resolved, as in previous versions of nuxi
Attaching the HAR file for more details: nuxi@3.8.3___nuxt3.7.3___wsl2___127.0.0.1.zip
The initial load is fast, no issues on speed
But after the initial load, _nuxt/ connection is refused, failing subsequent calls.
Behaviour accessing localhost
When loading localhost:3000, the content loading becomes extremely slow (in my system is over 8 seconds), loading all content and files correctly. After hydration, HMR continues working, although slow. Websocket connection is not refused/dropped, displaying "Pending" on the network tab, as expected.
Key points:
- SSR and content loading is correct but extremely slow
- After hydration, HMR continues working, although updates are slow.
- Network is still not resolved, as in previous versions of nuxi
Attaching the HAR file for more details: nuxi@3.8.3___nuxt3.7.3___wsl2___localhost.zip
The initial load is very slow, as is subsequent updates. Also, request display high values of stalling and queing.
Comparing with nuxi@3.6.5
Nuxi@3.6.5 does not display the above issues in both WSL2 and native windows environment.
Replication
- Create a blank project using
npx nuxi init(to install latest dependencies) - Run it with
npx nuxi@3.6.5 dev(nuxt will still be version 3.7.3) - Open
http://localhost:3000on a browser - Open
http://[detected_network]on a browser - Open
http://127.0.0.1:3000on a browser
Nuxi info:
Behaviour accessing localhost
SSR and content load very fast, as expected. Hydration is performed without issues, and HRM is maintained thoughout the dev mode. Network and 'localhost' resolved correctly, although 127.0.0.1 is not accessible.
Key points:
- SSR and content loading is correct and fast
- After hydration, HMR continues working, updates are instant.
- No websocket errors displayed, connection is constant.
- Network is resolved correctly.
- localhost is available
- the available network address for WSL2 access is resolved
- 127.0.0.1 is not available
@pi0 Thank you for the nuxi@3.8.4 release.
I've updated to nuxi@3.8.4 (npx nuxi@3.8.4 update --force), but the same behaviour continues,
Using npx nuxi dev or npm run dev still displayed the same behaviour.
I couldn't perceive any change in behaviour from the update.
However, I've realized that npx nuxi dev --host or npm run dev -- --host fixes the behavior when using http://localhost:3000, along with the correct resolution of the wsl address. Not sure if it is intentional, as in a new recomended workflow.
Speed is fast, and everything works as expected.
A small note is that when clicking the Local: http://localhost:3000 link, it still leads to http://127.0.0.1:3000 on the browser, instead of the expected http://localhost:3000. Using http://127.0.0.1:3000 doesn't work on my setup, which is usual for WSL2.
(Looking backwards at previous versions like nuxi@3.7.3, the --host parameter seems to has been working well all this time. Sorry for not realizing it earlier.)
Thanks for the updates. Do you mind to try experience with npx nuxi-edge@latest dev on your project? It should work fast with localhost as well now
Using the nuxi-edge@latest worked wonderfully!
npx nuxi-edge@latest dev returned the http://localhost:3000 and opened the correct URL on the browser.
Speed is fast, HRM is fast, and everything is working as expected!
Amazing work as always! 🙏
I'm running nuxi-edge@latest and it is still doing the same thing in wsl2.
117 requests for an empty Nuxt project
if I build and preview, 20 requests
@nathanchase Isn't that expected? While in dev mode, a lot of orquestration is happening to provide the best DX. Stuff like hot-module reloading, type generation, etc, IMO.
After build, everything is tree-shaked, minified, cleaned-up, compressed, so the webapp only uses what it really must use, and nothing else.
I can see that in dev mode, the full loading took 800ms, which is ok to develop.
When the bug I listed is present, it can take up more than 6 seconds (6.000ms) or more, and that's just too slow.
Also, many requests would be stalled, or queued up (the grey lines before the orange)
This is the project I'm currently working on - already with 10 modules, data fetching, image transformation, etc.
Is taking no more than 600ms. (the long first request is the data fetching to an external server)
Working great after the 3.9.0 release. Thank you so much!