Error on HMR reload

[sarunast]

I am trying to use fast refresh with WPS. With some components it works fine however with others, I get this error.

Plugin version 0.4.1
WPS: 1.0.1

main.js:558 Uncaught (in promise) Error: Aborted because ./src/client/views/home/HomeView.js is not accepted
Update propagation: ./src/client/views/home/HomeView.js -> ./src/client/views/routes.js -> ./src/client/app.js -> ./src/client/main.js -> 0
    at hotApplyInternal (main.js:558)
    at hotApply (main.js:412)
    at replace (hmr.js?797c:60)
hotApplyInternal @ main.js:558
hotApply @ main.js:412
replace @ hmr.js?797c:60
async function (async)
replace @ hmr.js?797c:47
eval @ client.js?a662:70

Any pointers where could the issue lie?

[gaearon]

This would need a minimal reproducing example. Could be a webpack bug.

[pmmmwh]

Other than a Webpack bug, this might be due to no available boundaries within the whole chain (i.e. no files in that chain contains only React components a-la PascalCase).

[sarunast]

(i.e. no files in that chain contains only React components a-la PascalCase)

@pmmmwh do you know where could I read more about this issue to understand it better?

Also. Do you have any idea why it doesn't reload the whole page instead if it fails to update? Because after the before mentioned error the page stops reloading.

[pmmmwh]

@pmmmwh do you know where could I read more about this issue to understand it better?

I don't have a definitive source for you, but React Refresh relies on exports' names to detect whether it is something we can accept (so does other dev tooling such as the hooks eslint plugin). So if a path of update propagation does not include anything we can accept, we unfortunately have to bail out.

Also. Do you have any idea why it doesn't reload the whole page instead if it fails to update? Because after the before mentioned error the page stops reloading.

It seems like Webpack's hot reloading crashed. I can help take a look at the actual config if you can provide it (with versions of webpack and react/react-dom used).

[sarunast]

I will close this issue for now. If I will manage to recreate a public example of the issue I will reopen the issue. Thanks for the help.

[desmap]

fwiw, I had something similar with webpack 5.0.0-rc.0; it worked without any errors with webpack 4.43.

The browser's log with 5.0.0-rc.0:

react_devtools_backend.js:2273 [HMR] Cannot apply update. Need to do a full reload!
overrideMethod @ react_devtools_backend.js:2273
module.exports @ log.js:26
eval @ dev-server.js:39
Promise.catch (async)
check @ dev-server.js:36
eval @ dev-server.js:55
emit @ events.js:153
reloadApp @ reloadApp.js:23
ok @ index.js:120
eval @ socket.js:48
sock.onmessage @ SockJSClient.js:67
EventTarget.dispatchEvent @ sockjs.js:170
eval @ sockjs.js:888
SockJS._transportMessage @ sockjs.js:886
EventEmitter.emit @ sockjs.js:86
WebSocketTransport.ws.onmessage @ sockjs.js:2962

react_devtools_backend.js:2273 [HMR] Error: Aborted because ./index.tsx is not accepted
Update propagation: ./index.tsx

Edit: I was somehow wrong, I also get the error with 4.43 :/ and the error differs slighlty:

VM2203 log.js:26 [HMR] Cannot apply update. Need to do a full reload!
module.exports @ VM2203 log.js:26
eval @ VM2202 dev-server.js:39
Promise.catch (async)
check @ VM2202 dev-server.js:36
eval @ VM2202 dev-server.js:55
emit @ VM2205 events.js:153
reloadApp @ VM2192 reloadApp.js:23
ok @ VM2172 client:119
eval @ VM2175 socket.js:47
sock.onmessage @ VM2176 SockJSClient.js:67
EventTarget.dispatchEvent @ VM2177 sockjs.js:170
eval @ VM2177 sockjs.js:888
SockJS._transportMessage @ VM2177 sockjs.js:886
EventEmitter.emit @ VM2177 sockjs.js:86
WebSocketTransport.ws.onmessage @ VM2177 sockjs.js:2962
VM2203 log.js:26 [HMR] Error: Aborted because ./index.tsx is not accepted
Update propagation: ./index.tsx -> 1
    at hotApplyInternal (...)
    at hotApply (...)
    at ...

[pmmmwh]

fwiw, I had something similar with webpack 5.0.0-rc.0; it worked without any errors with webpack 4.43.

I think it is quite contextual? It says that ./index.tsx is not accepted, but it is already at root so when we propagate it means a bail out (i.e. full refresh in browsers).

[desmap]

contextual

You mean "meaningful" or "clear" (...what the problem is)?

It says that ./index.tsx is not accepted, but it is already at root so when we propagate it means a bail out (i.e. full refresh in browsers).

Would you mind to elaborate?

Why does the tsx file end up being in the browser at all? webpack-dev-server should only access the dist folder with .js files. I'm a bit confused...

Edit: I've read in one of your other comments A valid refresh boundary is usually a file that contains only React-related exports (function components needs to be UpperCamelCase to be correctly detected) because there's no way we can guarantee that non-React exports are PURE in nature and side-effects free (thus auto-update-able). Since there's no file that conforms to the requirements for React-refresh to set up refresh boundaries on your update propagation path, we're forced to bail out and not apply the update.

So that means that at some point it's expected that your HMR bails out if no valid React component is found, right?! So everything is ok and this "error" you display is more kind of an information?!

Edit2:

• If I have an index.tsx which imports an App.tsx function compnent and renders it with ReactDOM => no refresh on change of App.tsx
• If I have an index.tsx which includes the App function component inline => refresh but this error above
• If I have index.tsx which has a bit of JSX like <div>...</div> and imports App.tsx and puts it between the divs like <div><App/ ></div> or right the the <App /> in ReactDOM.render(<App />, ... => all good on change of App.tsx but the error of above when changing index.tsx

I find this still confusing, so what is your suggested way to structure an app?

In any case if this error is just a warning or info, it should be changed, otherwise users get confused.

[pmmmwh]

(Sorry for missing this)

You mean "meaningful" or "clear" (...what the problem is)?

Yes.

Why does the tsx file end up being in the browser at all? webpack-dev-server should only access the dist folder with .js files. I'm a bit confused...

How webpack-dev-server and source error works is that they compile files on the fly and store them in memory - so index.tsx is not actually being served to the browser, it's just that the error originates from code within that file.

So that means that at some point it's expected that your HMR bails out if no valid React component is found, right?! So everything is ok and this "error" you display is more kind of an information?!

Yes. Let's say your component tree is like this: Component A -> index.ts (ReactDOM.render)

If Component A is changed and we can update it, fine we won't propagate the update (only Component A updates). But if the update from Component A defies what we require for a safe update, we would have to go to its parent. However, it's parent is also unsafe to update in place - so eventually we bubbled to "root" which means to the actual entry point of the JS - so the only way we can guarantee consistency is to bail out (in browsers this equals a full refresh).

That is also not something we print - it is what webpack-dev-server prints when it hits a bail out case.

• If I have an index.tsx which imports an App.tsx function compnent and renders it with ReactDOM => no refresh on change of App.tsx
• If I have an index.tsx which includes the App function component inline => refresh but this error above
• If I have index.tsx which has a bit of JSX like
  ...
  and imports App.tsx and puts it between the divs like
  <App/ >
  or right the the in ReactDOM.render(, ... => all good on change of App.tsx but the error of above when changing index.tsx

Refering to the case I've described above - the best way to avoid unnecessary bail outs when you edit code paths that is very close to root (i.e. ReactDOM.render) is to not have any JSX at all in the file you do ReactDOM.render.

This is because we only construct boundaries with exports, and the file containing ReactDOM.render would most likely not have any exports, thus will never have a boundary.

[baylac]

in case you haven't tried, restarting the computer did it for me

[jorgutdev]

I was able to solve the issue wrapping the app into a component

const container = document.getElementById('root')
const root = createRoot(container)
root.render(<App />)

Then add the browser router

export const App = () => (
<React.Suspense fallback="Loading...">
<AuthProvider>
<RouterProvider router={router} />
</AuthProvider>
</React.Suspense>
)

[julpat]

In my case, it was caused by additional export next to component export:

// removing export solved the issue
export const SOME_CONST = 'Value';

export default function SomeComponent({}) { ... }

[alvaro-escalante]

@julpat

In my case, it was caused by additional export next to component export:

// removing export solved the issue
export const SOME_CONST = 'Value';

export default function SomeComponent({}) { ... }

Thanks, I was going crazy with this and it was just that the moment there was a single export it worked!

[nyngwang]

@alvaro-escalante I, fortunately, succeeded on the first try since I didn't have any extra export. Now I'm curious why having more than one export will force it to full-reload.

On the other hand, it seems that the author of this plugin suggests that we should not use export default as it has many bad consequences, ref: TROUBLESHOOTING.md#edits-always-lead-to-full-reload.

[JeonChangMin15]

In my case, it was caused by additional export next to component export:

// removing export solved the issue
export const SOME_CONST = 'Value';

export default function SomeComponent({}) { ... }

You are my jesus. I love you so much!