Fred K. Schott

As far as I can tell those are the only differences, so it feels like we're actually not far off here! I added some more details to the README, so...

> I agree I haven't seen it in practice either and would be fine to leave this behavior undefined for now Of course right after I write this, I find...

The scenario would be an exported non-component function added to a module after-the-fact (file goes from all React components to 1+ non-React component exports). Does Vite's implementation handle that? Snowpack's...

If the interface makes sense so far, then I'm curious to talk about implementation details. I think I found an difference that affects how we would implement dependency whitelisting for...

Totally, this may be a difference between our implementations. Right now, in your example: ```js // main.js import foo from './foo.js' import.meta.hot.accept(['./foo.js'], ({module}) => { // Not shown: updating main.js...

That makes a lot of sense, and I can't think of any other good way to handle that otherwise without re-exporting your imports to grab them in the callback, which...

Awesome, I'm +1 to add to the spec.

@yyx990803 support for what you've described has been added. Based on what you've said, I think that's the last bit of Vite HMR that wasn't covered here, other than any...

Okay, I'm on board with moving data out of the callback. Since the `accept()` callback always runs in the original module context, we can essentially just support `import.meta.hot.data` as a...

> I think the implementation still needs to ensure the same data object is persisted across reload of the same module. Good point, this is given for free by our...