[NEXT-1103] Cannot read properties of null (reading 'useState') with Context Wrapper

[SamKomesarook]

Verify canary release

• [X] 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 22.4.0: Mon Mar  6 21:00:41 PST 2023; root:xnu-8796.101.5~3/RELEASE_ARM64_T8103
    Binaries:
      Node: 19.1.0
      npm: 8.19.3
      Yarn: N/A
      pnpm: N/A
    Relevant packages:
      next: 13.3.1-canary.11
      eslint-config-next: 13.3.0
      react: 18.2.0
      react-dom: 18.2.0

Which area(s) of Next.js are affected? (leave empty if unsure)

App directory (appDir: true), Data fetching (gS(S)P, getInitialProps)

Link to the code that reproduces this issue

https://github.com/Kiwi-Biosciences/debug

To Reproduce

When trying to build the project, it will fail with the following error:

TypeError: Cannot read properties of null (reading 'useState')

Describe the Bug

The build fails.

Expected Behavior

The build should succeed, as there are no visible logic or syntax errs.

Which browser are you using? (if relevant)

Firefox 112.0

How are you deploying your application? (if relevant)

AWS Amplify

_NEXT-1103

[elrumordelaluz]

This is now happening when upgrading next from v13.3.4 into v13.4.0. Not necessarily with

…(reading 'useState')

in the message, but all other hooks coming from react.

The builds are failing only when deployed on Vercel.

Related.

[Kuchasz]

The same thing happens on v13.4.0 with self-hosted apps.

[huozhi]

Have you tried latest patch 13.4.1 as we had a fix for that included in the patch? People mentioned in the thread that fixed their issue?

[jungpaeng]

I am experiencing the same issue with version 13.4.1.

[SamKomesarook]

@huozhi I have upgraded the demo to 13.4.1, tried building, and unfortunately it is still failing with the same err...

[jungpaeng]

As an aside, I'm using pages routing and it happened in a development environment, not a build environment.

[qiangfoo]

Same thing here, the build works locally, but fails on vercel.

[anil1712]

Any solution? I am getting the same since one week, using next 13.2.5

[simonmares]

Hi, another dev trying to use app dir alongside existing pages on a production app here.

I can reproduce this error using latest relevant packages:

"next": "^13.4.2",
"react": "^18.2.0",
"react-dom": "^18.2.0",

Build does only fail on Vercel, local next build is fine.

Specifics

We encountered this issue with swiper package, however the specific package is irrelevant, it's caused probably by Next bundling the third-party packages. This package is used only in pages routes.

Workaround

I added this package to transpilePackages which made the build finish.

Similar issues

• https://github.com/vercel/next.js/issues/49753
• https://github.com/vercel/next.js/issues/49355

[shuding]

For the original bug reproduction (https://github.com/Kiwi-Biosciences/debug), the cause was using async components inside a "use client" file, which is disallowed.

[anil1712]

Older versions are also not working for me, btw I am deploying the changes into AWS Lambda Serverless Stack

[benry1]

Same issue here.

App runs locally on NextJS 13.4.x, but fails with the same error after deploying to Lambda via SST. I am using 'next-auth', which I believe uses a Context wrapper.

My getServerSideProps completes with no issues, but before displaying the page the server throws the above as a 500 error.

Downgrading NextJS did not solve.

Edit: I dug a little further. This does not have to do with Context Wrapper, but getServerSideProps. Any use of SSR will cause this issue in SST... I ran with next@13.4.3-canary.2 locally and saw the same issue, but i gave this stack trace now: at deploy time:

 ERROR  Cannot read properties of null (reading 'useState')

 node_modules/.pnpm/react@18.2.0/node_modules/react/cjs/react.development.js:1622:21

 1619: }
 1620: function useState(initialState) {
 1621:   var dispatcher = resolveDispatcher();
 1622:   return dispatcher.useState(initialState);
 1623: }
 1624: function useReducer(reducer, initialArg, init) {
 1625:   var dispatcher = resolveDispatcher();

 - useState (node_modules/.pnpm/react@18.2.0/node_modules/react/cjs/react.development.js:1622:21)
 - DeploymentUI (node_modules/.pnpm/sst@2.8.26_@types+react@18.2.0_pg@8.11.0_typescript@5.0.4/node_modules/sst/cli/ui/deploy.js:9:39)
 -renderWithHooks (node_modules/.pnpm/react-reconciler@0.29.0_react@..+..+next.js+node_modules+react/node_modules/react-reconciler/cjs/react-reconciler.development.js:7478:18)

[anil1712]

@benry1 Yes, exactly same behavior I am experiencing.

[jlorezz]

https://github.com/vercel/next.js/issues/50158 is this issue related? Literally getting the same issue with the pages directory. Any update on this?

[huozhi]

Can someone provide a full reproduction here if the issue still exists or can confirm the issue is gone with latest canary?

[github-actions[bot]]

We cannot recreate the issue with the provided information. Please add a reproduction in order for us to be able to investigate.

Why was this issue marked with the please add a complete reproduction label?

To be able to investigate, we need access to a reproduction to identify what triggered the issue. We prefer a link to a public GitHub repository (template for pages, template for App Router), but you can also use these templates: CodeSandbox: pages or CodeSandbox: App Router.

To make sure the issue is resolved as quickly as possible, please make sure that the reproduction is as minimal as possible. This means that you should remove unnecessary code, files, and dependencies that do not contribute to the issue.

Please test your reproduction against the latest version of Next.js (next@canary) to make sure your issue has not already been fixed.

I added a link, why was it still marked?

Ensure the link is pointing to a codebase that is accessible (e.g. not a private repository). "example.com", "n/a", "will add later", etc. are not acceptable links -- we need to see a public codebase. See the above section for accepted links.

What happens if I don't provide a sufficient minimal reproduction?

Issues with the please add a complete reproduction label that receives no meaningful activity (e.g. new comments with a reproduction link) are automatically closed and locked after 30 days.

If your issue has not been resolved in that time and it has been closed/locked, please open a new issue with the required reproduction.

I did not open this issue, but it is relevant to me, what can I do to help?

Anyone experiencing the same issue is welcome to provide a minimal reproduction following the above steps. Furthermore, you can upvote the issue using the :+1: reaction on the topmost comment (please do not comment "I have the same issue" without reproduction steps). Then, we can sort issues by votes to prioritize.

I think my reproduction is good enough, why aren't you looking into it quicker?

We look into every Next.js issue and constantly monitor open issues for new comments.

However, sometimes we might miss one or two due to the popularity/high traffic of the repository. We apologize, and kindly ask you to refrain from tagging core maintainers, as that will usually not result in increased priority.

Upvoting issues to show your interest will help us prioritize and address them as quickly as possible. That said, every issue is important to us, and if an issue gets closed by accident, we encourage you to open a new one linking to the old issue and we will look into it.

Useful Resources

• How to Contribute to Open Source (Next.js)
• How to create a Minimal, Complete, and Verifiable example
• Reporting a Next.js bug
• Next.js Triaging issues

[benry1]

@huozhi Please find my minimal reproduction here: https://github.com/benry1/nextjs-ssr-fails

This requires SST to show the failure, but I am not sure if this is a NextJS or an SST issue.

[huozhi]

@benry1 have you tried with the canary version? it's still using the latest. Please provide a minimal reproduction that can be deploy on codesandbox or can develop locally, the one you linked requires aws credentials etc.

[benry1]

I tried the same after building the latest canary version locally, had the same issue. I wasn't sure how to embed that into the repo, so I left it as latest.

I can't reproduce this locally, it only happens when deployed on AWS, but it happens very consistently. Testing it will require aws credentials unfortunately. If that's not sufficient, feel free to re-tag this with please add a complete reproduction

[benry1]

Update: My issue was an SST related issue. It was using an incorrect version of open-next, this has been solved in SST 2.10.1.

[jeffrafter]

@benry1 I think I have run into the same issue but updating SST and any combination of next/next-auth isn't working for me. Any chance you could add some notes on how you debugged this and how you got the fix to work?

[dprothero]

I'm running into this issue on local builds. I'm not using sst:

Reproduced on this codesandbox:

Define the starting process: npx nx serve twilio-cli Try to load the /docs/twilio-cli route.

[jeffrafter]

This gives more info than I was seeing...

[jeffrafter]

@dprothero I was able to reproduce the error with your CodeSandbox.

I've tried a variety of version combinations and was still running into issues. In the end downgrading Next to ~13.2.4 solved it for me. There is likely another version in between that works. I've tested the latest canaries and still see the issue.

In the end

• sst@2.10.4
• next-auth@4.22.1
• next@13.2.4

Another note for the SST case. The deployment between newer and older versions changed pretty dramatically and the caching made things tough to debug. Hitting the lambda url directly made everything considerably easier. I was never able to reproduce this locally in any configuration.

[huozhi]

Few related fixes are released in 13.4.4, please try to upgrade to latest and test to see if the issue still existed. Will close this issue as there's no new reproduction testing against latest canary. If you still bumped to troubles, please file a new issue with minimal reproduction with latest canary.

[dprothero]

@huozhi No, the problem still exists with 13.4.4:

Updated codesandbox

[dprothero]

Thanks @jeffrafter, downgrading to Next 13.2.4 did work for now. Hopefully Next and/or Nx can solve this issue.

[huozhi]

@dprothero can you provide some repro steps? couldn't download from codesandbox and I found the repo, but there's no steps in readme how to start and how to repro the errors

[huozhi]

Sorry for missing the steps here. Looking into it

[huozhi]

@dprothero it's a nx problem for their current latest version (16.2.2) as they set __NEXT_PRIVATE_PREBUNDLED_REACT as process env which is shouldn't be set, I think it was a workaround for previous nextjs react mismatch issue.

function withNx(_nextConfig = {}, context = getWithNxContext()) {
    // If this is not set user will see compile errors in Next.js 13.4.
    // See: https://github.com/nrwl/nx/issues/16692, https://github.com/vercel/next.js/issues/49169
    // TODO(jack): Remove this once Nx is refactored to invoke CLI directly.
    forNextVersion('>=13.4.0', () => {
        var _a;
        process.env['__NEXT_PRIVATE_PREBUNDLED_REACT'] =
            // Not in Next 13.3 or earlier, so need to access config via string
            ((_a = _nextConfig.experimental) === null || _a === void 0 ? void 0 : _a['serverActions']) ? 'experimental' : 'next';
    });

Looked at their code it's remove in the code, but not published yet. I think you can wait for the next version or switch to a nx version without __NEXT_PRIVATE_PREBUNDLED_REACT env overriden

[github-actions[bot]]

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