lxsmnsyc
commented
7 months ago 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
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.dataas 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.datapersists 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.dataobject. 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...)