RangeError: Maximum call stack size exceeded when providing next with a config object parsed by node-config

[shaver-bigwx]

Link to the code that reproduces this issue

https://github.com/shaver-bigwx/next-node-config-bug-demo

To Reproduce

1. npm install
2. npm run build

Current vs. Expected behavior

Expected: next should be able to start

Actual: next fails to build / fails to start with a RangeError: Maximum call stack size exceeded in the output.

Provide environment information

npx --no-install next info
/[redacted]/next-bug-demo/node_modules/next/dist/server/config.js:1424
function cloneObject(obj) {
                    ^

RangeError: Maximum call stack size exceeded
    at cloneObject (/[redacted]/next-bug-demo/node_modules/next/dist/server/config.js:1424:21)
    at cloneObject (/[redacted]/next-bug-demo/node_modules/next/dist/server/config.js:1459:27)
    at cloneObject (/[redacted]/next-bug-demo/node_modules/next/dist/server/config.js:1459:27)
    at cloneObject (/[redacted]/next-bug-demo/node_modules/next/dist/server/config.js:1459:27)
    at cloneObject (/[redacted]/next-bug-demo/node_modules/next/dist/server/config.js:1459:27)
    at cloneObject (/[redacted]/next-bug-demo/node_modules/next/dist/server/config.js:1459:27)
    at cloneObject (/[redacted]/next-bug-demo/node_modules/next/dist/server/config.js:1459:27)
    at cloneObject (/[redacted]/next-bug-demo/node_modules/next/dist/server/config.js:1459:27)
    at cloneObject (/[redacted]/next-bug-demo/node_modules/next/dist/server/config.js:1459:27)
    at cloneObject (/[redacted]/next-bug-demo/node_modules/next/dist/server/config.js:1459:27)

Node.js v20.19.4

[next info fails with the bug too!]
[Rerunning this again with the buggy line commented out]

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.6.0: Mon Jan 19 22:01:41 PST 2026; root:xnu-11417.140.69.708.3~1/RELEASE_ARM64_T8132
  Available memory (MB): 24576
  Available CPU cores: 10
Binaries:
  Node: 20.19.4
  npm: 10.8.2
  Yarn: 1.22.22
  pnpm: N/A
Relevant Packages:
  next: 16.2.0-canary.72 // Latest available version is detected (16.2.0-canary.72).
  eslint-config-next: N/A
  react: 19.2.4
  react-dom: 19.2.4
  typescript: 5.9.3
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Not sure

Which stage(s) are affected? (Select all that apply)

next build (local), next start (local)

Additional context

Hello,

We've experienced this failure to start upgrading next to any version >15.5.x. We're on the pages router, but I am unsure if that's relevant. We use node-config to parse our config files per deployment environment and feed the parsed config object into next.config.js.

On next >15.5.x, npm run start fails with a stack overflow error. Please see the attached demo repo - npm run build / npm run start fail until the parsed config from node-config is commented out in next.config.js.

I have done some digging and I believe this is due to an interaction between node-config and next, after this commit changed how cloneObject works.
Before this change it looks like cloneObject would just enumerate all normal properties of the config object but afterwards it tries to enumerate accessors as well.

What I think is happening is node-config adds extra accessors to our config object when it parses it. Somewhere in the accessors added there is a cyclic reference. The new implementation of cloneObject gets stuck walking the tree infinitely and causes a stack overflow.

We'd like to keep using node-config if possible and obviously would like to be on the latest available version of next 15.x.x for bugfixes. I'm able to step around this issue by adding a patch file to revert cloneObject to its prior version but I don't fully understand why this function was changed / what the consequences of undoing that change would be.

Any help working towards a suitable fix would be greatly appreciated. Cheers!

[icyJoseph]

Is it possible for you to upgrade to config@4? I ran it with that version locally, and it builds fine.

[shaver-bigwx]

Great callout - it looks like they've fixed it by hiding the cyclic member in 4.4.0. We'll have a look at trying to modernise our config version.