Collecting page data .[RangeError: Maximum call stack size exceeded], static export can handle only limites pages

[Gul7333]

Link to the code that reproduces this issue

https://github.com/Gul7333/urdudictinory/actions/runs/15373691466/job/43256067868

To Reproduce

i have next js project which uses nextjs static export , the problem is my sttaic export is litle large like 100k+ pages , these pages are simple , when i build only 5000 pages it work but when i build full sttaic pages it fails

as this static param generte function work as i am slicing only 5000 pages

export function generateStaticParams() {
const slugs = dictionaryData.slice(0,5000)
.filter((item) => item && item[1]) // Filter out null/undefined and missing index
.map((item) => ({
slug: item[1],
}));
return slugs
}

but when i remove slice

// export const revalidate = 60
export function generateStaticParams() {
const slugs = dictionaryData.slice(0,5000)
.filter((item) => item && item[1]) // Filter out null/undefined and missing index
.map((item) => ({
slug: item[1],
}));
return slugs
}

it gives this errro
npm run build

urdudictinory@0.1.0 build
next build

▲ Next.js 15.3.2

• Environments: .env

Creating an optimized production build ...
✓ Compiled successfully in 60s
Skipping linting
✓ Checking validity of types
Collecting page data .[RangeError: Maximum call stack size exceeded]

Build error occurred
[Error: Failed to collect page data for /word/[slug]] { type: 'Error' }

Current vs. Expected behavior

i have next js project which uses nextjs static export , the problem is my sttaic export is litle large like 100k+ pages , these pages are simple , when i build only 5000 pages it work but when i build full sttaic pages it fails

as this static param generte function work as i am slicing only 5000 pages

export function generateStaticParams() {
const slugs = dictionaryData.slice(0,5000)
.filter((item) => item && item[1]) // Filter out null/undefined and missing index
.map((item) => ({
slug: item[1],
}));
return slugs
}

but when i remove slice

// export const revalidate = 60
export function generateStaticParams() {
const slugs = dictionaryData.slice(0,5000)
.filter((item) => item && item[1]) // Filter out null/undefined and missing index
.map((item) => ({
slug: item[1],
}));
return slugs
}

it gives this errro
npm run build

urdudictinory@0.1.0 build
next build

▲ Next.js 15.3.2
Environments: .env

Creating an optimized production build ...
✓ Compiled successfully in 60s
Skipping linting
✓ Checking validity of types
Collecting page data .[RangeError: Maximum call stack size exceeded]

Build error occurred
[Error: Failed to collect page data for /word/[slug]] { type: 'Error' }

Provide environment information

ubuntu 
Next.js 15.3.2

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

Dynamic Routes, dynamicIO, create-next-app

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

next build (local)

Additional context

No response

[teamleaderleo]

Hi @Gul7333,

I see you're aiming for a full static export of your Urdu dictionary with 100k+ pages to host on GitHub Pages. That's a cool project!

The error you're seeing, [RangeError: Maximum call stack size exceeded] happens when Node.js (which Next.js runs on) tries and fails to handle an extremely large number of synchronous operations or very deep function calls.

When you use Next.js's static export feature by setting output: 'export' your generateStaticParams function is called to list all the paths that need to be pre-rendered.

With 100k+ paths returned, Next.js then attempts to "collect page data" and render each of these pages into static HTML. This involves a series of operations for each page. When done for such a massive number in a single build process, it can exceed the call stack limit imposed by the underlying Node.js environment. It works for 5,000 pages because the total number of operations stays below this limit.

The challenge with output: 'export' for GitHub Pages at this scale:

GitHub Pages does not have a Node.js runtime, so Next.js features like Incremental Static Regeneration (ISR) can't be used because they require a server environment, and, as discussed above, the output: 'export' mode can struggle to build that many pages at once due to these limitations.

What you could do:

Use Next.js with a compatible hosting platform.

Platforms like Vercel https://vercel.com/ (which offers a generous free tier) or other Node.js compatible hosting platforms will fully support ISR. Your site will still be served statically and be very fast, but pages will be built more efficiently. This allows you to keep your existing Next.js project and scale effectively.

If sticking with GitHub Pages is a hard requirement:

This is more challenging with Next.js at this scale due to the build limitations.

Your workaround options are:

• Manual Chunking: You could try scripting multiple partial builds and merging the out directories. This is difficult to maintain.
• Increase Node Stack Size: Setting node --stack-size=8192 in node_modules/.bin/next build might offer a temporary reprieve but isn't a reliable fix.

Consider Alternative Static Site Generators (SSGs)

If the workarounds are too complex and GitHub Pages is non-negotiable, you might also consider alternative SSGs which are highly optimized for rapidly building a massive number of simple static pages from data. Examples include:

Hugo (Go-based)

https://gohugo.io/

Eleventy (JavaScript-based)

https://www.11ty.dev/

Zola (Rust-based)

https://www.getzola.org/

These options would all entail migrating your project's templating and data handling.

The Next.js team is always working on improving build performance, but for your immediate needs and scale, shifting your deployment strategy to use ISR on a compatible platform is likely the most straightforward path to success with your Next.js dictionary.

[Gul7333]

Thanks
But I think nextjs team should impove it's logic of static build as my project is very simple even though it's 100k pages , it would only take 8minute to build all pages , so next js shouldn't raise error for such small time consuming project
I thinks It is problem with next js logic , if the team can improve the static build code , it would work fine

[teamleaderleo]

Hi @Gul7333,

I get your perspective. I glimpsed at the code to understand how Next.js does stuff under the hood.

For context, with the way Next.js currently pre-renders HTML, they'd likely have to shift their process to be fully stream-oriented, or to use iterators/generators to process the massive list of pages in a way that keeps the call stack shallow and memory usage low.

This would be a significant architectural change, and would likely cost a nontrivial amount of maintainability. Next.js has a complex build system that caters to a lot of different rendering modes (SSR, ISR, RSCs, static).

The current system already has chunking (in export/index.ts sending work to workers) and workers already have internal concurrency limits (as seen in export/worker.ts).

However, the RangeError: Maximum call stack size exceeded suggests that either:

• The main thread orchestrating these chunks/workers is still doing too much synchronous work over too many iterations.
• Or, a worker itself, when processing its assigned (potentially still large) chunk of pages, has an internal loop that is too synchronous over too many iterations, leading to a stack overflow within that worker process.

So, more batching, or perhaps different kinds of batching (like yielding to the event loop within tight loops) might be needed. "Little optimizations" might not cut it if the fundamental issue is call stack depth over a massive number of iterations.

They absolutely could look at how tools like Eleventy, Hugo, Zola, etc., achieve their massive static build performance, but the challenge for Next.js would be integrating such highly specialized static-gen techniques into its much broader, more hybrid architecture without compromising its other features or significantly increasing complexity. A deeper fix to make output: 'export' as scalable as a dedicated SSG for hundreds of thousands of pages would be a much larger undertaking for the Next.js team with significant design and maintenance considerations, some of which might differ from where their current priorities lie.

Anyway, based on the current behaviour, I also opened a PR (#80037) to potentially add a more descriptive warning for this situation.