fix(module-runner): allow already resolved id as entry#19768
fix(module-runner): allow already resolved id as entry#19768patak-cat merged 6 commits intovitejs:mainfrom
Conversation
|
/ecosystem-ci run |
commit: |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
|
📝 Ran ecosystem CI on
✅ analogjs, astro, marko, vite-plugin-react-swc, vite-plugin-pwa, react-router, previewjs, vite-plugin-cloudflare, qwik, histoire, vite-plugin-react, rakkas, ladle, waku, vite-setup-catalogue |
There was a problem hiding this comment.
I think #19283 should be fixed. On the other hand, I'm not sure about #19764. I prefer to be not fixed and keep the behavior as-is. But that'd require a complex refactor (probably, the normalization for browsers, which is also done for the module runner, needs to be removed) and I think it's not the right time to do that. To sum up, I think we can go with this PR. But I think we should have a test for #19283 as that's the reason why we are changing the behavior here.
Description
ssrLoadModule("/@id/__x00__virtual:xxx")fails on Vite 6 #19764[vite] cannot find entry point module ...error when a runner full reloads with a virtual module entry #19283I thought ensuring entry module resolveId makes sense, but that's causing inconsistency with how already resolved virtual module id is handled in other places. I think we can remove this to match
transformRequestbehavior in general. Otherwise, I'm not sure how to fix #19283.I didn't add a test case for #19283, but confirmed the repro is fixed https://stackblitz.com/edit/github-i1t4t7n4?file=repro.js(EDIT: added in "virtual module hmr")