Build crashes with JavaScript heap out of memory (OOM) during rolldown bundling on large i18n content collection

Astro Info

Astro                    v7.1.6
Node                     v24.15.0
System                   macOS (arm64)
Package Manager          pnpm
Output                   static
Adapter                  none
Integrations             @astrojs/mdx
                         @astrojs/sitemap

Note: installed via https://pkg.pr.new/astro@0edeae0 (commit 0edeae0), which resolves to v7.1.6.

If this issue only occurs in one browser, which browser is a problem?

N/A — build-time failure, not browser-specific.

Describe the Bug

Running astro build on a static site with a large i18n content collection (~5,000 posts × 45 locales ≈ 225,000 markdown entries) crashes with FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory during the "Building static entrypoints" phase (rolldown).

Content sync, types generation, and "Collecting build info" all complete successfully. The OOM happens in the rolldown native bundler invoked from the JS thread — the native stack trace points into @rolldown/binding-darwin-arm64 (rolldown-binding.darwin-arm64.node). Heap climbs to ~4 GB, GC cannot reclaim (mu degrades 0.246 → 0.015), then aborts.

Reproduction repo

https://github.com/AlanBreck/astro-memory-error-repro

pnpm install
pnpm run build

Project structure

• One blog collection loaded via glob({ base: './src/content/blog', pattern: '**/*.{md,mdx}' }).
• Posts live as src/content/blog/post-XXXX/index.{locale}.md — 5,000 posts, each with 45 locale variants (en, es, fr, de, ja, zh, …, ar) → ~225,000 markdown files (242,570 files total including images).
• astro.config.mjs declares 45 i18n.locales with prefixDefaultLocale: false.
• Dynamic route src/pages/[...lang]/blog/[...slug].astro uses getStaticPaths() → getCollection('blog'), generating one path per (post, locale).

Error output

12:44:20 [build] Building static entrypoints...

<--- Last few GCs --->

[14831:0xae940c000]   122251 ms: Mark-Compact 4064.8 (4098.7) -> 4064.3 (4103.7) MB, pooled: 0 MB, 1783.67 / 0.00 ms  (average mu = 0.246, current mu = 0.015) allocation failure; scavenge might not succeed
[14831:0xae940c000]   124272 ms: Mark-Compact 4069.1 (4103.7) -> 4066.1 (4105.4) MB, pooled: 0 MB, 1878.88 / 0.96 ms  (average mu = 0.160, current mu = 0.070) allocation failure; scavenge might not succeed

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----

 1: node::OOMErrorHandler(...) [/Users/jacoblamont/.nvm/versions/node/v24.15.0/bin/node]
 2: v8::internal::V8::FatalProcessOutOfMemory(...)
 3: v8::internal::Heap::stack()
 4: v8::internal::Heap::CollectGarbage(...)
 ...
19: [/Users/jacoblamont/Sites/playground/astro-memory-error-repro/node_modules/.pnpm/@rolldown+binding-darwin-arm64@1.1.5/node_modules/@rolldown/binding-darwin-arm64/rolldown-binding.darwin-arm64.node]
 ...
[ELIFECYCLE] Command failed.

What works / what doesn't

• ✅ Content sync completes (~26s): 12:43:56 [content] Syncing content → 12:44:20 [content] Synced content
• ✅ Types generation completes: 12:44:20 [types] Generated 26.14s
• ✅ Collecting build info... ✓ Completed in 26.17s.
• ❌ Building static entrypoints... → OOM.

What's the expected result?

astro build should either complete within default Node heap limits for this scale, or fail with a clear, actionable error (rather than an OOM native crash) indicating the entry/path count limit and suggested mitigations (e.g. chunked builds, partitioning, or a NODE_OPTIONS=--max-old-space-size=… recommendation).

Questions for the team

1. Is there a known upper bound on collection entries / static paths per build, and is it documented?
2. Is the per-entry memory retention in the rolldown integration expected, or is this a leak?
3. Any recommended pattern for partitioning builds across this many i18n routes (e.g. one build per locale)?

Link to Minimal Reproducible Example

https://github.com/AlanBreck/astro-memory-error-repro

Participation

• I am willing to submit a pull request for this issue.