perf: Improve memory cache on build#23286
Conversation
WalkthroughThis PR updates apps/web/next.config.js by enabling experimental.webpackMemoryOptimizations and experimental.webpackBuildWorker, extending the webpack config function to accept the dev flag, and configuring a non-development immutable in-memory cache when config.cache exists. It also updates turbo.json to include NEXT_PUBLIC_API_V2_URL, NEXT_PUBLIC_WEBAPP_URL, NEXT_PUBLIC_WEBSITE_URL, and BUILD_STANDALONE in the globalEnv array, with a formatting change adding a trailing comma after CSP_POLICY. Possibly related PRs
Tip 🔌 Remote MCP (Model Context Protocol) integration is now available!Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats. ✨ Finishing Touches
🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
Status, Documentation and Community
|
Graphite Automations"Add consumer team as reviewer" took an action on this PR • (08/22/25)1 reviewer was added to this PR based on Keith Williams's automation. "Add ready-for-e2e label" took an action on this PR • (08/22/25)1 label was added to this PR based on Keith Williams's automation. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
apps/web/next.config.js (1)
199-201: Add env-toggle “kill switches” for experimental webpack flags
- Confirmed that
apps/web/package.jsondeclares Next.js v15.4.5, which supports bothexperimental.webpackMemoryOptimizationsandexperimental.webpackBuildWorker.- Gating these behind environment variables lets you quickly disable them (e.g. in CI or canary rollouts) without code changes.
File:
apps/web/next.config.jsexperimental: { // externalize server-side node_modules with size > 1mb, to improve dev mode performance/RAM usage optimizePackageImports: ["@calcom/ui"], - webpackMemoryOptimizations: true, - webpackBuildWorker: true, + webpackMemoryOptimizations: + process.env.NEXT_EXPERIMENTAL_WEBPACK_MEMORY_OPTIMIZATIONS !== "false", + webpackBuildWorker: + process.env.NEXT_EXPERIMENTAL_WEBPACK_BUILD_WORKER !== "false", },turbo.json (1)
253-257: Scope CSP_POLICY, NEXT_PUBLIC_API_V2_URL and BUILD_STANDALONE to web tasksOur grep confirms that only
apps/webreferences these three vars (middleware, Next.js config, CSP/lib logic, proxy’ing, tests) and nowhere else in the monorepo:
- CSP_POLICY is used exclusively by
apps/web(middleware.ts, next.config.js, lib/csp.ts, middleware.test.ts) and in the website build task’senvblock.- NEXT_PUBLIC_API_V2_URL only appears in
apps/web(next.config.js proxy, SSR helpers, feature flags) and in two task-specificenvarrays.- BUILD_STANDALONE only toggles Next.js’s
output: "standalone"insideapps/web/next.config.js.By contrast, NEXT_PUBLIC_WEBAPP_URL and NEXT_PUBLIC_WEBSITE_URL are referenced across packages—constants, seed scripts, APIs, embeds, mail templates, UI components, tests, etc.—so they belong in
globalEnv.Action items (all in turbo.json):
- Remove
"CSP_POLICY"from the top‐levelglobalEnvand leave it in the website build task’senv(around lines 358–362).- Remove
"NEXT_PUBLIC_API_V2_URL"and"BUILD_STANDALONE"fromglobalEnv, retaining them only in their respective task‐scopedenvblocks (around lines 311–317 and 253–256).- Keep
"NEXT_PUBLIC_WEBAPP_URL"and"NEXT_PUBLIC_WEBSITE_URL"inglobalEnv, since they’re consumed by many packages.This refactor isn’t required for correctness but will limit cache invalidations to the web‐only tasks.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (2)
apps/web/next.config.js(2 hunks)turbo.json(1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
**/*.{ts,tsx,js,jsx}
⚙️ CodeRabbit configuration file
Flag default exports and encourage named exports. Named exports provide better tree-shaking, easier refactoring, and clearer imports. Exempt main components like pages, layouts, and components that serve as the primary export of a module.
Files:
apps/web/next.config.js
⏰ Context from checks skipped due to timeout of 180000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Install dependencies / Yarn install & cache
🔇 Additional comments (2)
apps/web/next.config.js (2)
236-237: Includingdevin the webpack callback signature — LGTMThis allows precise prod-only tweaks; no concerns here.
237-244: Use a mutable memory cache instead of freezing the configOverriding
config.cacheto{ type: "memory" }in production is a solid optimization to reduce filesystem churn, but freezing that object can lead to hard-to-debugTypeError: Cannot assign to read only property ...errors if Next.js or any plugin tries to augment cache settings later. JavaScript’sObject.freezemakes all properties non-writable, which provides no real benefit during build but can break downstream mutations.• In
apps/web/next.config.js(around lines 237–244), replace:- if (!dev) { - if (config.cache) { - config.cache = Object.freeze({ - type: "memory", - }); - } - }with:
+ if (!dev && config.cache) { + config.cache = { type: "memory" }; + }Optional rollback guard (no code changes needed later):
- if (!dev && config.cache) { - config.cache = { type: "memory" }; - } + if (!dev && config.cache && process.env.NEXT_USE_MEMORY_CACHE !== "false") { + config.cache = { type: "memory" }; + }Please run a full production build (locally or in CI) both with and without this change (and with
NEXT_USE_MEMORY_CACHE="false") to measure RSS/heap differences and build-time impacts, ensuring you don’t introduce OOM risk in your environment.
|
Looks like the dev build here took 18 minutes to fully be ready, which is right around existing times for dev builds. |
E2E results are ready! |
2 participants
What does this PR do?
Following NextJS Guide https://nextjs.org/docs/app/guides/memory-usage#try-experimentalwebpackmemoryoptimizations
I introduced some memory optimizations to avoid build OOM errors.