I have same issue

I'm also seeing this in a production environment, so I'm not sure HMR is the sole responsible for the issue

@ernerock I deployed the above example here but the issue doesn't seem to occur once live. Were you able to reproduce in a production environment?

@malimccalla It seems my issue is different from yours, however the navigation behavior is the same. When the page I navigate to has a css import

import 'react-alice-carousel/lib/alice-carousel.css';

the navigation behaviour is the same as you reported. Seems to be an issue with '@zeit/next-css'

Seems to be reported already in #5291 , can be 'solved' temporarily by importing and empty css file in _app.js

@ernerock Very odd, they may be related in some roundabout way!

Same issue here, I have pages set up as /home and /home/subpage, then if I try to navigate from /home to /home/subpage with Router.push, or withRouter HOC or even Link it doesn't work.

Okay now I have some more info, I tried to rename /home to /home/welcome and the case described above still doesn't work for me

@maciej-ka Ah yes I can confirm it also happens with push it's not just Link. Will change the title, as its a bit misleading.

@timneutkens Sorry to @ you I know there are loads of other issues but any chance we can get some eyes on this? I've been trying to get to the bottom of it for a week now with no luck and it's really blocking development

It's most likely related to on-demand-entries and their disposal

I did a bit of digging and it seems it happens due to the pages being disposed of. As soon as this log appears the disposed pages can no longer be navigated to

> Disposing inactive page(s): /

I have a bit of time tonight to do a deeper dive and can hopefully get a PR open to fix it. @timneutkens Thanks for the initial insight, let me know if you think theres any part of that file I should be looking at in particular

I did have a look at trying to fix this but there is a lot going on in the related files and unfortunately I couldn't quite get to the bottom of it. For anyone else having this issue, as a current workaround I'm using this configuration in my next.config.js to extend the duration before pages get disposed.

  onDemandEntries: {
    // period (in ms) where the server will keep pages in the buffer
    maxInactiveAge: 25 * 1000,
    // number of pages that should be kept simultaneously without being disposed
    pagesBufferLength: 5,
  },

I have this issue as well.

Is someone looking into this? I also have this issue but not necessarily to all the routes. It's random which route/routes become unresponsive but they all do eventually.

I can't look into it right now as I'm focusing on the next-server/lambdas issue, but it's most likely related to on-demand-entries.

Yup, it sure is. Happens after dispose.

Same with me.

Can someone confirm for me that this is not an issue in production?

Can someone confirm for me that this is not an issue in production?

In production mode its ok, after I've changed ENV to production everything is going ok

I have this in both dev and production. Doesn't matter if the page is inactive, etc. I can have a fresh load and it won't work. In dev, the server console
> Building page: /contact
WAIT Compling...
success client complied in 462ms
but the page never renders in the client. At the same time, on the client console:
[HMR] bundle rebuilding message, then the server console gives:
Disposing of inactive page(s): /, /contact

If I type mysite.com/contact into the browser, it will load just fine.
I've tried the work around in next.config.js of maxInactiveAge and pagesBufferLength to no avail.

[was hoping it was just in dev as many were saying]

EDIT: I did have an import 'node-mod/dist/theme.css in a component. I moved that import to _app.js and that Link is working.

Same issue here, route do not complete in dev mode after dispose. It is really annoying.

@roytsang Instead of saying "same issue" use 👍 on the issue. Your manual +1 doesn't end up being taken into account when sorting on 👍

I have the same issue. It only started today after I started using Head from next/head in my _app to apply a title and favicon.

@Atmospheres have you tried @malimccalla workaround solution? It wasn't a total fix but worked for me as a workaround.

I haven't gotten around to it yet, but I will soon. I just thought more information on when the problem arose for me might be useful to someone looking into a fix.

Update: I've been doing some testing this morning and here's what I've come across.

Problems started yesterday, the only new thing I had implemented is the Head from next. I realized I changed the head in _document, used to load in styles, to Head. I also added Head to _app.js to set title and favicon. Removing Head in _app.js did not fix this for me. Removing Head in both _app and _document also didn't resolve the issue. I tried one last thing, I reverted Head in _document back to head and left the Head in _app to set title and favicon, and now the issue is gone.

If for any reason the issue returns I'll update here again. I hope this info might help lead to a fix.

Update 2: The problem persists, though it arises less frequently then it did. I have noticed that when it does happen, I see the script tag that loads the js for that page is duplicated. For example, first time I load page "x" it adds to the body. Now this script tag should only be added to the body once, but on the times it fails to load I see the script tag added a 2nd, and then if I click the link again it is added a 3rd time, and so on. These additional script tags are only added a few times while staying on the same page and clicking the link, however if I navigate to another page and back to where the link was, I can click it and add several more script tags.

Update 3: Problem happens after a while on a single link. Tested loading my home page and not clicking anything, after a couple minutes the Elements tab in Chrome dev tools flashes, I'm assuming a HMR, and ALL Links were broken. I hope all of this information wasn't just a waste of time for you guys. The issue doesn't seem to be happening in production, so I guess I'll just ignore it for the moment.

I haven't gotten around to it yet, but I will soon. I just thought more information on when the problem arose for me might be useful to someone looking into a fix.

Update: I've been doing some testing this morning and here's what I've come across.

Problems started yesterday, the only new thing I had implemented is the Head from next. I realized I changed the head in _document, used to load in styles, to Head. I also added Head to _app.js to set title and favicon. Removing Head in _app.js did not fix this for me. Removing Head in both _app and _document also didn't resolve the issue. I tried one last thing, I reverted Head in _document back to head and left the Head in _app to set title and favicon, and now the issue is gone.

If for any reason the issue returns I'll update here again. I hope this info might help lead to a fix.

Update 2: The problem persists, though it arises less frequently then it did. I have noticed that when it does happen, I see the script tag that loads the js for that page is duplicated. For example, first time I load page "x" it adds to the body. Now this script tag should only be added to the body once, but on the times it fails to load I see the script tag added a 2nd, and then if I click the link again it is added a 3rd time, and so on. These additional script tags are only added a few times while staying on the same page and clicking the link, however if I navigate to another page and back to where the link was, I can click it and add several more script tags.

Update 3: Problem happens after a while on a single link. Tested loading my home page and not clicking anything, after a couple minutes the Elements tab in Chrome dev tools flashes, I'm assuming a HMR, and ALL Links were broken. I hope all of this information wasn't just a waste of time for you guys. The issue doesn't seem to be happening in production, so I guess I'll just ignore it for the moment.

I think I also noticed the same thing a long ago, the day I shifted from NextJs 5 to NextJs 6 but ignored it since it's just dev problem. My production is working fine :)

I'm investigating this issue right now.

Solved in #5994

Is it possible to let us know what the problem was and how we might be able to work around the issue if we can't upgrade right now? For instance, is it to do with css loading? Is it something that can be changed in config?

@jon64digital I wrote a complete writeup of this issue in #5994, you could work around it by upping the disposal time limit.

@timneutkens i'm using 8.1.1-canary.24 and the bug still exists for me. Any idea?

Edit: found out whats happening. Not sure why tho...:
I had an index.tsx and index.less file. I was using cssModules in my netxt.config.js file (using withLess). When loading a /subpage and having a link that references / (which is importing styles like this: import css from './index.less';) then the script will be dynamically loaded (http://localhost:3000/_next/static/development/pages/index.js) but it is not rendered. In fact the url doesn't change at all, it's like stuck... Removing the less file import resolved the issue.

Wat do?

Edit2: Seems I'm running into https://github.com/zeit/next-plugins/issues/282

I still get this happening some times too on 8.1.0. I will try to reproduce and open a new issue

for me too its not navigate to /about route gives 404 every time! not sure what the issue with routing!? :/

package.json dependencies:

"dependencies": { "cross-env": "^5.2.0", "express": "^4.17.0", "next": "^8.1.0", "react": "^16.8.6", "react-dom": "^16.8.6" }

@jsbimra please always provide a full reproduction. It's impossible to look into "happens for me"

@jsbimra please _always_ provide a full reproduction. It's impossible to look into "happens for me"

found an issue, it was related to step missing in creating a page under page folder of next.js, sorry to bother @timneutkens

any solution for this? does this happen too in production? because in dev it's happening to me, the bug it's from 2018 and May/22/2019 still this bug hasn't been fixed, if this doesn't happen in production I'm not that concerned, but if it happens then this is a really big problem...

the bug it's from 2018 and May/22/2019 still this bug hasn't been fixed

Based on the provided reproduction by @malimccalla it has been fixed.

if this doesn't happen in production I'm not that concerned

It doesn't.

Note that this comment is not going to solve your issue. As said many times before:

please always provide a full reproduction. It's impossible to look into "happens for me"

I have the same issue with the latest version (8.1.0).

I have the same issue with the latest version (8.1.0).

I've now replied about 3 times with the exact same message. Please provide a reproduction.

Note that this comment is not going to solve your issue. As said many times before:

please always provide a full reproduction. It's impossible to look into "happens for me"

I was troubled by the problem of not being able to access ~ / index.tsx.
But I finally found the cause!

I used a library called react-activity , but at the same time I needed to import css.

When I read the same css twice in different places, it seems that I can not migrate.
As a result of reading in _app.tsx, I was able to migrate successfully.

@timneutkens okay, sure, I can increase the disposal time, but what about the situation where the server is started for the first time? I won't be able to navigate to those pages programmatically because they are not built yet. 🤔

I've now replied about 4 times with the exact same message. Please provide a reproduction.

Note that this comment is not going to solve your issue. As said many times before:

please always provide a full reproduction. It's impossible to look into "happens for me"

To answer the specific question, pages are built on-demand, and this system works fine. I assume you have something in your configuration that makes webpack not trigger the file as finished building. However it's hard/impossible to say because there is no reproduction.

Also note that the specific issue, as mentioned earlier, was already fixed and that increasing the timeout does not help for the specific issue you're experiencing. Hence why I keep asking for a reproduction 🙏.

We're super happy to look into this and spend time on it.

I created a new project yesterday and it worked just fine. There has to be something specific about my project that makes it not work. I will try to gradually take it apart later today and see at which point the problem disappears.

I'd love to take a look if you can reliably reproduce it.

The good news is that I was able to pinpoint the error. The bad news is that the issue with my project was no different to what other people, in this thread, have reported.

So if the issue is with CSS and disposal limit, and it supposedly has been solved, I must be doing something wrong. Is this where you put these?

module.exports = withCSS({ onDemandEntries: { maxInactiveAge: 1000 * 60 * 60 } })

Reproduction: https://github.com/dydokamil/next-js-router-bug

@dydokamil
It is known bug: https://github.com/zeit/next-plugins/issues/282
You can "solve" it importing an empty CSS file.

I can get this to reliably reproduce across dev, production and static-export modes and none of the onDemandEntries or empty css file workarounds helped.

The only way to fix the problem was to remove import 'highlight.js/styles/color-brewer.css'; from the Body component on my blog post pages.

Any <Link> instance that pointed to a blog post page would fail to load but http://localhost:3000/_next/static/development/pages/post.js still would get dropped on the page on <Link> click. Comment out that css import, <Link>s to blog posts work perf. Uncomment and all <Link>s fail to load blog posts.

Hitting any of those blog post page routes directly work fine, the bug is only related to client-side -based routing. This happened after upgrading from version 6 to version 8.

I hit initially this with @zeit/next-css but I can replicate this issue in the same way after swapping in @zeit/next-sass and importing a .scss file. For now I'm just gunna load these styles using styled-components drop @zeit/next-css. After reviewing https://www.npmjs.com/package/@zeit/next-css and https://www.npmjs.com/package/@zeit/next-sass, it seems like those Usage examples would break 🤔

Could you add a reproduction repository to https://github.com/zeit/next-plugins/issues/282

What you're describing sounds exactly like that issue.

I can get this to reliably reproduce across dev, production and static-export modes and none of the onDemandEntries or empty css file workarounds helped.

The only way to fix the problem was to remove import 'highlight.js/styles/color-brewer.css'; from the Body component on my blog post pages.

Any <Link> instance that pointed to a blog post page would fail to load but http://localhost:3000/_next/static/development/pages/post.js still would get dropped on the page on <Link> click. Comment out that css import, <Link>s to blog posts work perf. Uncomment and all <Link>s fail to load blog posts.

Hitting any of those blog post page routes directly work fine, the bug is only related to client-side -based routing. This happened after upgrading from version 6 to version 8.

I hit initially this with @zeit/next-css but I can replicate this issue in the same way after swapping in @zeit/next-sass and importing a .scss file. For now I'm just gunna load these styles using styled-components drop @zeit/next-css. After reviewing https://www.npmjs.com/package/@zeit/next-css and https://www.npmjs.com/package/@zeit/next-sass, it seems like those Usage examples would break 🤔

After adding next/css package I can confirm this happened to me as well.

The same happened to me in development (production works as expected), and the issue is when we link to pages (or have components inside) that import sass files.

My next.config.js file:

const withSass = require('@zeit/next-sass');

const withBundleAnalyzer = require('@next/bundle-analyzer')({
  enabled: process.env.ANALYZE === 'true',
});

require('dotenv').config();

module.exports = withBundleAnalyzer(
  withSass({
    distDir: '../dist',
    env: {...},
  }),
);

So then, one of the components in depth have this import:

// MIGRATE: PriceDetail to styled components
import './PriceDetail.scss';

When I comment the import, the link starts working. So it seems to be an issue with withSass plugin.

I have similar issue but not same. Unfortunately I get same error
in production too. But for some reasons links work sometimes.

I've encountered the same issue with next 9.4
I added CodeMirror yesterday to my project and also
import "codemirror/lib/codemirror.css"

I have something like pages/page2.js which does some stuff then calls router.replace("/") at the end of that and it just suddenly stopped doing anything.
Running router.replace("/") in the debugger showed a promise that never resolves or hits catch or finally blocks.

Also possibly worth noting is that I do have next-css in my next.config.js - I'm going to try to remove it and see if that has any impact.

Looks like maybe there's a hot fix here? =)

Aha, that fixed things for me - I obviously also had to move my import to a shell _app.js file too.