next build command fails with some inner error

[ivan-kleshnin]

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.

[ivan-kleshnin]

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]

Update-2

There are more bugs unfortunately. Added a demo here: https://github.com/ivan-kleshnin/buildbug
Basically a skeleton project which fails to build.

It demonstrates another, even more fundamental bug. Unless I'm doing something wrong.

[nummi]

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,
}

[Timer]

Closing as stale. Please let us know if this still reproduces.

[jserrao]

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.

[amykapernick]

I'm having this issue as well on 10.0.1

[amykapernick]

I'm having this issue as well on 10.0.1

[robbertvancaem]

@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 :-)

[amykapernick]

@robbertvancaem I am and I did, but that made no difference. I also had several other pages which had separate page files, whilst also meeting a [slug].js file, and none of them caused any issues. I just had one page that did it

[alexburner]

Seeing this on 10.0.5, I too would appreciate a better error message. It's a mysterious break to investigate, and hard to search for — nextjs syscall: 'rename' finally got me here.

The filter() fix worked for me, too.

@Timer can this issue be re-opened?

[alexburner]

Oh, looks like there's already a fix merged into vercel:canary #20918

[quantizor]

This recently happened to me and it turned out I was accidentally building a page twice (via multiple spots where there are dynamic routes) and next.js emitted a similar error for the second instance the page would have been created because the file had already been copied over.

[andrewf414]

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.

[timneutkens]

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

[jacobdubail]

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 :)

[fchristl]

Maybe this helps someone: I ran into the same error message because I had null values in the return value of getStaticPaths.

[vandercloak]

I am running into this issue because I have a [storyId].js in the root of /pages. One of the story ids is 404 and so I get a naming collision error in the build.

Does anyone know if there is a way to change the built in 404 path to something else (i.e. change 404.html to 404-error.html). I searched the docs and did not find the answer (but could be missing it).

I could nest 1 folder deeper to avoid the collision, but I am using a basepath of /stories (needed for a reverse proxy) already and was hoping to avoid another nest (i.e /stories/404 -> /stories/story/404).

[balazsorban44]

This issue has been automatically locked due to no recent activity. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.