-
-
Notifications
You must be signed in to change notification settings - Fork 98
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Import with compilerOptions breaks HMR #577
Comments
query params getting encoded after a refresh sounds like a generic vite problem. Are you able to reproduce it in a vanilla vite project with Apart from that i'd be interesting if you elaborated on your usecase a bit. These advanced queries are still experimental, very new and not meant for general use. (see remark at the top of the docs). Would love to learn more. Maybe open a thread on https://svelte.dev/chat in Also cc @rixo, having a self-accepting module also accept updates of direct children sounds like something up his alley. |
I was able to reproduce the issue in a vanilla Vite project: Steps:
Looking at the source code in Chrome dev tools shows that after the change in main.js, the import statement of counter.js has been corrupted: |
It was a bit confusing that counter isn't mounted in the example but i see the behavior. simply using the encoded form from for json isn't a workaround either as it would lead to double encoding for the Can you report this to vite with a link to here? |
Describe the bug
I have a bit of an unusual use case, where I need to have access to both DOM and SSR compiled versions of a Svelte component in the frontend. I achieved this without a problem by using the "compilerOptions" import query option as described in advanced uses:
import AppSSR from './App.svelte?svelte&direct&type=script&compilerOptions={"generate":"ssr"}';
But this is causing some weird behavior with HMR. I'm assuming vite-plugin-svelte only supports HMR for normal dom compiled components, which is fine, but it seems to me that the JSON in the compilerOptions param breaks any possibility of implementing the HMR yourself. I believe the problem is that
&compilerOptions={"generate":"ssr"}
is sometimes converted into&compilerOptions={%22generate%22:%22ssr%22}
, which breaks HMR because there is no module accepting HMR events for this corrupted path and this results in hard refreshes. So it seems to me that the import paths are URL encoded at some point, but then not appropriately decoded.I'm unsure if this encoding is happening because of this plugin or because of how Vite handles import paths. I can investigate this further, but felt like it might be a good idea to create an issue first.
There is also of course the possibility that the problem is not in Vite or this plugin but that I've just misunderstood something in how to set up the HMR boundary, in which case sorry for the spam and do go ahead and close this issue :)
Reproduction URL
https://stackblitz.com/edit/vitejs-vite-5npyoj?file=src/main.js
Reproduction
Logs
No response
System Info
The text was updated successfully, but these errors were encountered: