Stabilizing experimental.hmrPartialAccept

[patak-dev]

hmrPartialAccept

• Introduced in vite@3.0.0
• Rationale in Original PR and Discussion
• Not documented
• Used by svelte-hmr

We're looking for feedback to decide if we should move this feature out of experimental in Vite 5 (or keep the discussion open if we want to do it in future versions). @rixo, it would be great if you could kick-start the discussion. I think at this point Svelte is the only user for this feature, but that may change if properly documented and made stable.

[rixo]

Hi! I'm obviously super biased but I think the feature is worth stabilizing, and I also believe it is ready to do so.

I won't repeat all the details that can be found in the original discussion, but the gist of it is that it generalizes the existing HMR principle of reflecting code changes in well known hot reload capable boundaries, by having changes traverse unknown code until those boundaries are met. The novelty is that whereas current HMR works at module level, partial accept increase the granularity to individual exports in a module.

This increased granularity is desirable because module level HMR has no way of properly addressing modules with mixed exports, where some can be hot reloaded but not all of them. Most frameworks with HMR capabilities have to deal with this situation and, currently, they have to chose between knowingly introducing HMR glitches by accepting modules that they know they can't fully handle, or not accepting them, but at the cost of reducing the surface of code that can be hot reloaded (potentially by a lot). Partial accept allows to handle the situation correctly by accepting only those exports you know you can manage, and let the existing HMR mechanisms do the rest.

I expect that adoption of the feature by any framework that allows modules with mixed exports would be a net benefit to their end users HMR experience, because it removes a case that we know is currently broken. The adoption is very straightforward, because HMR providers (frameworks) already have to know what exports they are concerned with, in order to instrument them with HMR. They just have to spell them out to the dev server to enable partial HMR support.

In Svelte we have thought long and hard about how we could address the problem with the traditional module-level hot reload, but anything we've come up would have been far too heavy handed to implement. We would have had to split users' modules into acceptable and non acceptable parts, and rewire everything between those and others (local variables, scopes, exports, imports...). With partial accept supported by Vite, we've got the problem solved with a one line change in our HMR engine.

I also think that the feature as it is currently implemented in Vite is complete. The current API we have is nice. And since the initial implementation in Vite, we've never had to go back and fix or adjust anything. It has just worked for us, so I suppose the feature is also pretty stable on Vite's side.

All in all, I believe the feature can improve HMR experience for the users of multiple frameworks, at a minimal cost of implementation for the adopters, and a very bearable cost for Vite itself. So I am personally all in favor of pushing the feature toward a more official status. I would be happy to provide the documentation for it, if it is decided to move into this direction.

[patak-dev]

Thanks a lot for the detailed write-up about your experience with this feature (and for proposing and implementing it in the first place!). Let's leave this discussion open for a while and discuss it in a future team meeting. Having docs for the feature will be great and I think we could add them even before the feature is stabilized so we increase the chances of folks trying it out. But if you'd like to wait, that is fine too.

[pcattori]

Remix has non-component exports in HMR boundaries. Specifically, Remix routes can export handle, headers, links, meta, and shouldRevalidate. Note that loader and action exports are server-only and are already removed from the route via transformation, so those are not of concern here.

We've been experimenting with Vite as a replacement for the Remix compiler and would love to reuse @vitejs/plugin-react:

import { defineConfig } from 'vite'

import { remix } from '@vitejs/plugin-remix' // pretend this exists
import react from '@vitejs/plugin-react'

export default defineConfig({
  plugins: [remix(), react()],
})

However, React Refresh does not handle component and non-component exports in the same file for the same reasons outlined here. I also considered creating virtual modules for each route file, one for all component exports and another for non-component exports. But I'd like to find a solution that doesn't make the dependency graph different in prod and dev if possible, not to mention that splitting things up like that could also be a significant perf hit.

Spoke to @ArnaudBarre about this today and still wrapping my head around all the problem and possible solutions, but this seems at least potentially related.

[patak-dev]

@rixo we talked with the team, and given that Remix may be exploring the use of this feature soon, we think it is better that it stays as experimental until they have time to play with it so we get feedback from two different frameworks before stabilizing it

[rixo]

Yes, I have been in contact with Pedro from Remix. And sure, it makes sense to get the feedback before committing to an API.

[pcattori]

We ended up not needing hmrPartialAccept and instead pass a list of special Remix exports along. We're working with @ArnaudBarre on a more general API from vite-plugin-react that will let us use it directly rather than vendoring it within Remix.