Skip to content
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

runtime output for the 'esm' bundler does not refresh #65

Open
Alloyed opened this issue Apr 9, 2024 · 1 comment
Open

runtime output for the 'esm' bundler does not refresh #65

Alloyed opened this issue Apr 9, 2024 · 1 comment

Comments

@Alloyed
Copy link

Alloyed commented Apr 9, 2024

So this is a follow up from this discord convo!

https://discord.com/channels/722131463138705510/723573901862371449/1222612734835953764

Quick recap. Refresh was not triggering for us. We use a custom esbuild-based bundler, our ESM implementation was originally based on the 'esm' spec published by snowpack here:

https://github.com/FredKSchott/esm-hmr

In particular, we were implementing the behavior of import.meta.hot.data as described in this document, where it is reset before the module is imported and any refresh callbacks are called.

https://github.com/FredKSchott/esm-hmr?tab=readme-ov-file#importmetahotdata

However, the 'esm' transform in solid-refresh actually implements the vite interpretation, where import.hot.meta.data persists between reloads:

https://vitejs.dev/guide/api-hmr#hot-data

This matters for this line in particular, where the registry is stored in the hot.data object. for esm-compliant bundlers this means the registry it blown away every update.

https://github.com/solidjs/solid-refresh/blob/main/src/runtime/index.ts#L289

Since the snowpack and this spec itself is EOL I don't necessarily think that solid-refresh needs to change to support it. 'esm-hmr' support could instead be completely dropped or deprecated. We updated our HMR implementation to match vite's instead internally.

(pour one out for documented standards...)

@lxsmnsyc
Copy link
Member

lxsmnsyc commented Apr 10, 2024

Honestly I'm a bit neutral. The only reason I still continued implementing this despite knowing Snowpack has been dead for almost 2 years, is that there are other bundlers that follows the spec (I forgot which) and so this whole "esm" thing is just a fallback if ever a bundler happens to be providing this support, the same way I have "standard" for bundlers like Parcel

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants