getStaticProps crashes on next 12.2.0 when building

[statusunknown418]

Verify canary release

• I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
Platform: darwin
Arch: arm64
Version: Darwin Kernel Version 21.5.0: Tue Apr 26 21:08:37 PDT 2022; root:xnu-8020.121.3~4/RELEASE_ARM64_T6000
Binaries:
Node: 18.2.0
npm: 8.5.5
Yarn: 1.22.19
pnpm: 7.3.0
Relevant packages:
next: 12.2.0
eslint-config-next: 12.1.6
react: 18.1.0
react-dom: 18.1.0

What browser are you using? (if relevant)

not relevant

How are you deploying your application? (if relevant)

No response

Describe the Bug

Only when the export const getStaticProps = () => { ... } function is added, the pnpm build crashes displaying the following error.

• Note: Using @chakra-ui

Code

• Note: fetcher is a custom wrapper for the native fetch API that nextjs pollyfills.

Expected Behavior

Build shouldn't crash and getStaticProps should be working as expected

Link to reproduction

unable to reproduce

To Reproduce

1. boot starter ts project
2. install chakra ui and set it up
3. add getStaticProps in any page
4. run yarn build

[ShonFrazier]

I first experienced a problem with 12.2.0 when our CI pipeline attempted to next start after a successful build. Here's the error from the attempted launch:

Jun 29 04:52:44 ip-10-11-18-224 web: > @<redacted>@0.1.0 start
Jun 29 04:52:44 ip-10-11-18-224 web: > next start
Jun 29 04:52:44 ip-10-11-18-224 web: warn  - You are using a non-standard "NODE_ENV" value in your environment. This creates inconsistencies in the project and is strongly advised against. Read more: https://nextjs.org/docs/messages/non-standard-node-env
Jun 29 04:52:44 ip-10-11-18-224 web: warn  - You are using a non-standard "NODE_ENV" value in your environment. This creates inconsistencies in the project and is strongly advised against. Read more: https://nextjs.org/docs/messages/non-standard-node-env
Jun 29 04:52:44 ip-10-11-18-224 web: ready - started server on 0.0.0.0:8080, url: http://localhost:8080
Jun 29 04:52:44 ip-10-11-18-224 web: TypeError: Cannot convert undefined or null to object
Jun 29 04:52:44 ip-10-11-18-224 web: at Function.keys (<anonymous>)
Jun 29 04:52:44 ip-10-11-18-224 web: at NextNodeServer.getEdgeFunctions (/var/app/current/node_modules/next/dist/server/next-server.js:656:23)
Jun 29 04:52:44 ip-10-11-18-224 web: at NextNodeServer.generateCatchAllMiddlewareRoute (/var/app/current/node_modules/next/dist/server/next-server.js:991:22)
Jun 29 04:52:44 ip-10-11-18-224 web: at NextNodeServer.generateRoutes (/var/app/current/node_modules/next/dist/server/base-server.js:464:41)
Jun 29 04:52:44 ip-10-11-18-224 web: at new Server (/var/app/current/node_modules/next/dist/server/base-server.js:109:48)
Jun 29 04:52:44 ip-10-11-18-224 web: at new NextNodeServer (/var/app/current/node_modules/next/dist/server/next-server.js:62:9)
Jun 29 04:52:44 ip-10-11-18-224 web: at NextServer.createServer (/var/app/current/node_modules/next/dist/server/next.js:128:16)
Jun 29 04:52:44 ip-10-11-18-224 web: at async /var/app/current/node_modules/next/dist/server/next.js:137:31

Since that time, a new project, created with npx create-next-app@latest will not build, producing @AlvaroAquijeDiaz 's error message from above.

Reproducing this bug does not require step 2 above in 'To Reproduce"

Current workaround: specify "next": "12.1" in package.json

[msabramo]

Thanks, @ShonFrazier! Since this only affects starting a built app with next start and not running the dev server with next dev, I opted to keep the version of next the same in package.json and I just added the following to our Dockerfile that we use for building the app for production deployments:

RUN npm install next@12.1.6

Our Dockerfile is a variation of this:

FROM node:14.9.3-slim

COPY package*.json .

RUN npm install
RUN npm install next@12.1.6

COPY . .

ENTRYPOINT ["npm", "start"]

[msabramo]

It looks like this is not occurring with Next.js in git on the canary branch. I have commit a1504f4.

$ pnpm next build ./examples/basic-css/
...
$ pnpm next start ./examples/basic-css/

> nextjs-project@0.0.0 next /Users/abramowi/dev/git-repos/next.js
> node --trace-deprecation --enable-source-maps packages/next/dist/bin/next "start" "./examples/basic-css/"

ready - started server on 0.0.0.0:3000, url: http://localhost:3000

It looks like someone has fixed this.

[msabramo]

I'm not an expert in this code, but I wonder if perhaps:

• The breakage occurred here, since this appears to have the effect of no longer writing a functions property to the middleware manifest (.next/server/middleware-manifest.json)
• This was fixed here, which seems to have reintroduced the functions property to the middleware manifest.

Someone with more knowledge of the code might be able to verify if these theories are true.

In any case, it does seem to work with the latest version on canary right now in git, so something appears to have fixed the problem.

[mztnnrt]

Today, We build nextjs with same Dockerfile, but docker image size is large and changed, and this error is occured.
So, we update nextjs 12.1.6 to 12.2.0, it is resolved.

[statusunknown418]

Hey, I've made a fresh pnpm i and build (with no .next or .swc dirs) and it's still crashing under the same situation. Any ideas to fix this?

[mztnnrt]

@AlvaroAquijeDiaz If you use 12.1.6, changing version i.g. 12.2.0, may be the error gone.

[statusunknown418]

@mztnnrt it's updated but the error persists 🙁

[BertrandBordage]

This appears to have been fixed in the newly released 12.2.1.
Was this fixed by #38178?

[statusunknown418]

Haven't tested 12.2.1 yet but on 12.2.0 canary it would still break up

[DuyBui1993]

I upgrade nextjs version from 12.1.5 to 12.3.0 and experiences the same with @ShonFrazier , this happen only on page that using getStaticProps + getStaticPaths.

next start -p 8000
ready - started server on 0.0.0.0:8000, url: http://localhost:8000
TypeError: Cannot convert undefined or null to object
    at Function.keys (<anonymous>)
    at NextNodeServer.getEdgeFunctions (/home/webapp/node_modules/next/dist/server/next-server.js:989:23)
    at NextNodeServer.runApi (/home/webapp/node_modules/next/dist/server/next-server.js:438:36)
    at NextNodeServer.handleApiRequest (/home/webapp/node_modules/next/dist/server/next-server.js:795:21)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async Object.fn (/home/webapp/node_modules/next/dist/server/next-server.js:719:37)
    at async Router.execute (/home/webapp/node_modules/next/dist/server/router.js:247:36)
    at async NextNodeServer.run (/home/webapp/node_modules/next/dist/server/base-server.js:346:29)
    at async NextNodeServer.handleRequest (/home/webapp/node_modules/next/dist/server/base-server.js:284:20)

[BertrandBordage]

@DuyBui1993 I don’t have the issue on 12.3.0 🤔

[statusunknown418]

Anyone using latest version and having the issue as well?

[jakobo]

This appears fixed in 12.3.1. My .next/server/middleware-manifest.json was moved to version 2 when I ran next build after upgrading, and the file includes the functions block.

{
  "sortedMiddleware": [],
  "middleware": {},
  "functions": {},
  "version": 2
}

[BertrandBordage]

Actually I still experienced a few crashes with 12.3.0 & 12.3.1, just less than before. They were only on the client side, they happened during hydration.
This sandbox reproduces the bug: https://codesandbox.io/s/nextjs-middleware-hydration-crash-ew460x?file=/pages/%5B%5B...path%5D%5D.tsx
But it's not happening in 100% of cases. I have the issue consistently when I use Chrome 102 (not in incognito mode) and go to a path called /index.php (other paths with an extension don't crash)

Fortunately, this appears to have been fixed by this PR: #41243. When I upgrade to the latest Canary release the error no longer occurs 😃
So hopefully, another bunch of crashes you experienced could be finally solved by 12.3.2.

[leerob]

Hey there, going to close this out as stale since there isn't a reproduction provided, but if you are still seeing this on the latest version of Next.js, please open a new issue 🙏

[github-actions]

This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.