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

Created on 11 May 2020  路  10Comments  路  Source: vercel/next.js

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.

bug needs investigation

Most helpful comment

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

All 10 comments

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.

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.

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

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

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.

I'm having this issue as well on 10.0.1

I'm having this issue as well on 10.0.1

hi

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

Was this page helpful?
0 / 5 - 0 ratings