next.js: next build command fails with some inner error

Bug report

Describe the bug

$ next build throws an error at optimization step:

Automatically optimizing pages...

> Build error occurred
[Error: ENOENT: no such file or directory, rename '/Users/username/Projects/projectname/.next/export/blog.html' -> 
'/Users/username/Projects/projectname/.next/serverless/pages/blog.html'] {
  errno: -2,
  code: 'ENOENT',
  syscall: 'rename',
  path: '/Users/username/Projects/projectname/.next/export/blog.html',
  dest: '/Users/username/Projects/projectname/.next/serverless/pages/blog.html'
}

for pages/blog/index.js file with the following getStaticProps

export async function getStaticProps() {
  let url = "/blog"
  let knex = await import("knex/client").then(m => m.default)
  let page = await knex("page")
    .select("title", "seoTitle", "body")
    .filter({url})
    .firstRequired()
  return {
    props: {page, ogType: "website"},
  }
}

It looks like some bug in NextJS build pipeline to me.

It started with recent NextJS and Now updates though I can’t tell the particular breaking update at this moment. Can it be related to Now CLI 19.0.0? I dunno how to downgrade this tool to an earlier version.

Extra info:

It doesn’t happen with getServerSideProps or with purely static pages.
It doesn’t happen with $ next dev.

To Reproduce

I can make a sandbox if necessary.

Expected behavior

next build should work 🤷

System information

OSX
Browser (if applies) [e.g. chrome, safari]
Version of Next.js: tried with 9.3.5, 9.3.6, 9.3.7
Version of Now: tried with 19.0.0, 19.0.1
Version of Node.js: 12.16.3

Notes

Besides trying different NextJS versions I tried rm -rn node_modules and yarn cache clean. No effect on the bug.

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 1
Comments: 19 (6 by maintainers)

Most upvoted comments

Also running into this issue:

/pages/[uid].js
/pages/index.js

In getStaticPaths, I filter out index.

const pages = await ...

const paths = pages.results
  .filter((page) => {
    return page.uid !== 'index'
  })
  .map((page) => ({
    params: { uid: page.uid },
  }))

return {
  paths,
  fallback: true,
}

nummi on May 22, 2020

Update

The error is not a NextJS bug but rather a special case for which reporting can be improved.

I handle the same object at pages/blog/index.js as a blog page and, at the same time at pages/[...slugs].js as a generic page.

pages/[...slugs].js

export async function getStaticPaths() {
  return {
    paths: [... "/blog" ...] // among other things!
    fallback: true,
  }
}

Which causes the above conflict. I’ll leave it up to you guys how to treat such cases. IMO they should be recognized and reported in some clear way.

ivan-kleshnin on May 11, 2020

@amykapernick Are you using dynamic routes? In my case, I had a page [slug].js that tried to render a page with slug contact. However, I didn’t want that, since contact was already defined in a separate contact.js. This causes a conflict where Next cannot know which one to use. The solution was to filter out the contact slug in [slug].js.

Hope it helps 😃

robbertvancaem on Nov 11, 2020

I find this a pretty frustrating bug. I’ve had it come up a few times (and always have to resolve by filtering out dynamic paths), but the issue comes up where you are creating dynamic paths (like [blog]) and then make a static one that needs to be a snowflake for whatever reason. I actually had the build succeed locally, but fail when deployed to Vercel. So not sure what is happening there. It is a bug as far as I understand though, given the docs for next.js provide the caveat that “Predefined routes take precedence over dynamic routes, and dynamic routes over catch all routes”. So it should just overwrite the files IMO.

andrewf414 on Jul 2, 2021

I ran into the same issue this morning. My issue, in case anyone else is in a similar situation: Headless WordPress. Client created a page with a slug that was the same as one of our dynamic routes. Spent hours debugging my codebase until I thought to check. Hope this saves someone else, or me 3 months from now 😃

jacobdubail on Aug 25, 2021

@andrewf414 can you create a new issue with a reproduction, we’d be happy to take a look.

timneutkens on Jul 2, 2021

I got this error on v9.5.1 FWIW. Same issue - trying to do an override of [].js template with name.js and Webpack bonks. A better error message would be ideal.

jserrao on Sep 21, 2020