Bug? Named exports in top level components break HMR

[fatso83]

I had a day long debugging session to get to the bottom of why HMR was not working in my app, and it turns out a simple export const foo = 12 at the (almost-)top-level component was enough to break HMR. While that was the reason, I do not understand why it is so. Could someone explain this to me?

Background discussion

Background with minmally reproducible case: https://github.com/fatso83/break-vite-hmr-with-export

The single line needed to screw up HMR: fatso83/break-vite-hmr-with-export@e3159d5#diff-26ad4b834941d9b19ebf9db8082bd202aaf72ea0ddea85f5a8a0cb3c729cc6f2R7

---

Edit: got a tips on where to look for clues in Discord

[fatso83]

I have tried debugging this and I know approximately where in the code stuff happens, but 20 breakpoints and 2 hours later I still haven't really figured this out. Mostly because I do not understand the code at a conceptual level and how the lexer works, I suppose.

I wrote this on the Vite discord after researching the code around https://github.com/vitejs/vite/blob/main/packages/vite/src/node/server/hmr.ts#L121:

Turns out debugging this in IntelliJ (=WebStorm) was a breeze. Just fire up the node_modules/vite/bin/vite.js in a debugger and off I went. Unfortunately, I was unable to get to the bottom of this before leaving work, even after spending a couple of hours 😦 I got this far

• You were def right about the isDeadEnd flag being set, leading to a reload. That in turns is caused by isSelfAccepting being set to true in the importAnalysis.transform() method. I don't actually understand really what all of this does, though :slight_smile:
• With and without the export being prefixed, you end up in importAnalysis.transform() after Chokidar emits a "change" event. It's the branching in here that I have been unable to fully step through, but I see that without export it ends up lexAcceptedHmrDeps and with export it doesn't.

That's about it. I know the method where it happens, but not exactly why/how or which line the logic diverges. Nothing in the code greps for export, so I am guessing the actual work is done in es-module-lexer or something.

[AkashKumarVerma]

Any update on this issue.

I am facing this issue with SolidJS. Updating JavaScript works fine but updating JSX or CSS doesn't work.
The update is correctly picked up and updated, but the browser is not reloaded. Upon manually reloading the browser i can see the correct updates.

[fatso83]

I found out I could hack around this by simply moving the export to another file. You might find that is the least invasive solution.

[DorianBlues]

I found out the reason that cause this problem is isLikelyComponentType method in @vite/plugin-react.

If your entry file export a module which not match the rule defined in isLikelyComponentType, then the file will not be injected the impot.hot.accept() code and lead to a full-reload.

There is a discussion about this:
facebook/react#16604

[fatso83]

The link backed by the url text is broken, btw.

[pmmmwh]

Hi, maintainer of the Webpack integration of React Refresh here, maybe I can chime in and provide some insights ... (This answer only relates to the React parts of HMR)

TL; DR: This is intentional behaviour, and is necessary to provide guarantees that the HMR would end up in a consistent state.

The reason why it doesn't work is that the additional export is not considered as a component (well, CamelCase functions/classes). If a file contains any exports that is not a component, the transform will not mark the component as side-effects free. This is important because anything else other than a component is generally not guaranteed to be side-effects free, but if there are side-effects, to have HMR work properly someone would need to work on cleaning up the side-effect, which is not possible cause what effect it is firing is unknown.

With that in mind, and also with the knowledge that HMR would propagate up in the dependency tree, sometimes you will see interesting cases that a single line would break HMR for the whole app because that line is close to the root.

[galaxynova1999]

1. remove other named exports out of component file
2. make export like this: export default function List() {} // (P.S CamelCase)
3. then HMR works perfectly fine

I was wonder, why does webpack + webpack-react-hmr doesn't have this problem?

[yarinsa]

1. remove other named exports out of component file

2. make export like this: export default function List() {} // (P.S CamelCase)

3. then HMR works perfectly fine

I was wonder, why does webpack + webpack-react-hmr doesn't have this problem?

I am assuming that's because webpack builds a consistent cache of the state. It "mocks" modules system, and can cache their state.

@fatso83 If I understand the problem correctly.

@fatso83 is there a way to contribute and solve this issue?

[pmmmwh]

I was wonder, why does webpack + webpack-react-hmr doesn't have this problem?

They do have the same problem - I'm not sure what setup with Webpack your are referring to, but for example react-hot-loader uses clever tricks and patches internals to try and get this to work, and this also means when they don't your application will be inconsistent. We value consistency and reliability.

I am assuming that's because webpack builds a consistent cache of the state. It "mocks" modules system, and can cache their state.

To be clear, this is a react refresh specific 'problem' - we intentionally implement it that way and tell bundler to fall back to full reload when we cannot confirm this change will be side-effects free.

[tommyrharper]

I was wonder, why does webpack + webpack-react-hmr doesn't have this problem?

They do have the same problem - I'm not sure what setup with Webpack your are referring to, but for example react-hot-loader uses clever tricks and patches internals to try and get this to work, and this also means when they don't your application will be inconsistent. We value consistency and reliability.

I am assuming that's because webpack builds a consistent cache of the state. It "mocks" modules system, and can cache their state.

To be clear, this is a react refresh specific 'problem' - we intentionally implement it that way and tell bundler to fall back to full reload when we cannot confirm this change will be side-effects free.

The default create-react-app setup doesn't have this problem though, and it uses @pmmmwh/react-refresh-webpack-plugin. Do you know why that is @pmmmwh ? Or anyone else?

[folmert]

1. remove other named exports out of component file
2. make export like this: export default function List() {} // (P.S CamelCase)
3. then HMR works perfectly fine

It doesn't work for me. I'm on Vite v.5.0.12.
I've moved a created store into a separate file and every time I make a change in the codebase it still does a full page refresh instead of HMR.

import storeModules from '@/store'
import { createStore } from 'vuex'

const Store = createStore({
  ...storeModules,
})

export default Store

This Store is imported in main.ts, router and 2 helper JS files.

Edit: I've ended up using Vue's provide/inject instead of importing the store from file and that fixed HMR for me.

[Angrigo]

For people googling: ViteJS HMR loop through modules and breaks when you have a named export in your top-level.

[fatso83]

Breaks when you have a non-CamelCased export. See the accepted answer for details and why this prevents bugs. Just move your exports elsewhere.

[timsofteng]

Any tricks to make it work without default exports injection?

[lucas-teks]

It's a bit annoying because you'll have to import like so import { MyComponent } from "MyFile" but
✅ you can do:

export {
 MyComponent
}

✅ for variables, HMR won't invalidate doing this:

const foo = 12
export {
 foo,
 MyComponent
}

❌ however, for functions, it will invalidate doing so:

let myFn = () => {}
export {
 myFn,
 MyComponent
}

✅ you still can trick around the isLikelyComponentType function by also adopting a PascalCase naming to your exported functions, like a component function (which is far from ideal):

let MyFn = () => {}
export {
 MyFn,
 MyComponent
}