Navigating to another _non-built_ page should navigate after page has built successfully.
Navigating to another _non-built_ page reloads the page after intended page has built successfully. Clicking to navigate again after the intended page has been built, correctly routes to the page.
Just more of a pain in development because we aren't sure that it isn't happening in a production build without double checking every time.
I am running a custom express server with custom document and app.
| Tech | Version |
|---------|---------|
| next | v6 |
| node | v9.11.1 |
| OS | Windows 10 |
| browser | Chrome 66 |
| etc | |
Please provide a clear way to reproduce, essiest way for us go check it out is a repository.
I've had similar issue. I was trying to modify config.entry in next.config.js ...
When I tried to navigate to non-built page I got [HMR] The following modules couldn't be hot updated: (Full reload needed)...
Problem was with my custom webpack configuration. I was appending Service worker registration file like this:
const oldEntry = config.entry
config.entry = () =>
oldEntry().then(entry => {
entry['main.js'].push(path.resolve('./utils/sw-install'))
return entry
After I wrapped it inside if(!dev)... HMR started to work again.
After upgrading to Next 6 / babel 7 I am also seeing some inconsistency in page rendering and getting (full reload needed). It applies to routes that have not been been previously built, so pretty close to what @stramel described
Looks like this is related to https://github.com/zeit/next.js/issues/2060
UPDATE: I had some old directive in next.config.js, @rosenbergdev thanks!
@timneutkens I haven't been able to reproduce it yet. However I have tracked down that it seems while the page is building, HMR sends a message saying the _app file has changed ("{"action":"change","data":["/_app"]}") and is causing it to reload the current page.
Any thoughts?
https://gist.github.com/stramel/bfcf2c8d2572f92a344bfc6247a51f08
Got the same issue when importing global styles in _document.js file but I don't understand why.
I just do this in _document.js
import '../global-styles.scss';
It seems to come from @import directives in css
@import url('https://fonts.googleapis.com/css?family=Open+Sans:400,400i,700');
@import "~react-draft-wysiwyg/dist/react-draft-wysiwyg.css";
Then I got the same issue as @stramel with the {"action":"change","data":["/_app"]}" sent by the hot reload server.
@tlenclos I appreciate your input on this issue. I still haven't found a way to fix this issue across the board. I did manage to bandage one page by moving selectors from an external file into the same file as the page. However this didn't work across the board.
When the selectors were in another file, HMR reported about 30 files changed including _app.js. (No actual files were changed, just clicked a link for navigation on the localhost)
When the selectors were in the same file as the page, HMR reported no file changes/updates and properly routed.
@timneutkens I have been unable to reproduce this scenario in a repo yet but it does seem that HMR is firing false positives on file changes. It seems very arbitrary but I'm sure there is a central issue. I will continue to keep digging.
I pulled out the _app.js file and it seemed to fix the HMR issue. I'm working to reproduce this.
Update: This fixed pages that were not using actions in the getInitialProps. I re-added the _app.js and pulled out a component that appeared to be causing a lot of re-renders on _app.js that also fixed the pages that were not using actions in the getInitialProps function.
I have it down to using an action function from another file causing the error and inlining the action works properly.
I already postet my issue here: #2060
In my case it seems to be a Problem with polyfill. As I remove the polyfill settings the navigation works as expected but I can't use the app properly on IE11 because of missing functionality.
@yves-s @makstr This doesn't appear related to #2060. This is happening on the latest Chrome and seems directly tied to the HMR. I have also checked my next.config.js for outdated config.
@stramel I probably faced the same problem. Try to downgrade react-hot-loader to version "4.0.1" - it fixes the problem for me.
@Everettss How did you downgrade it to 4.0.1? Just specify it in the package.json dependencies?
@stramel Oh it's not a temporary solution - only for debugging purposes:
npm i [email protected] --save-exact
and then remove dir:
node_modules/next/node_modules/react-hot-loader
Doing so helped me with finding that problem you mention is related to version react-hot-loader 4.1.0 and above.
Hmmm didn't work for me... Maybe related to #4232 or #4310?
Appears that #4388 may have fixed part of the issue with my setup.
Now I am getting:

Error: Loading chunk 6 failed.
with this as my dist folder:

The undefined chunk is a problem with dynamic(import('path/to/module'))
I disabled that in hopes that it might work or be able to debug further...
The routing is /_document even though I am trying to route to /network/:networkId in dist/client/webpack-hot-middleware

Seems that the hot-reloader.js is properly detecting that I want to route to /networks however the client webpack-hot-middleware-client.js is detecting a change in /_document?

UPDATE: The styled-components are causing the _document to say there are changes.

Which causes webpack-hot-middleware-client.js to reload the page on /login
Tried downgrading to styled-components#^2.1.0 as the example uses but it is still causing a reload...
When I remove the styled-components it works. Will see if I can reproduce now.
@stramel can you try latest canary? I applied a fix for something similar to your issue yesterday.
@stramel interesting that it says /_document is updated too 馃 Let me add a check for that too.
New canary version that also filters out _document is on the way: https://travis-ci.org/zeit/next.js
@timneutkens That did the trick!!! 馃帀 馃帀 馃帀 Fixed with 6.0.3-canary.1 (Not fixed with 6.0.3-canary.0. I appreciate you taking a look at my debugging notes and figuring out the issue!
Thanks for the extensive debugging from your side 馃槍 It wasn't the easiest issue to find :+1:
@timneutkens I am still facing this issue with [email protected] I put up a repo here https://github.com/madhums/nextapp-hotreload-issue
@madhums expecting your issue will be fixed by https://github.com/zeit/next.js/pull/4497, @alexindigo made a minimal example in which it still failed.
@timneutkens I confirm it fixes the issue! Thanks! Good job!
Great @madhums!
Hi Tim, I still face this issue. Not really sure what the problem is! Tried 6.0.4-canary.3 also. I am trying to make a repo which can reproduce.
Most helpful comment
New canary version that also filters out _document is on the way: https://travis-ci.org/zeit/next.js