fix(frontend): raise ng serve heap limit to avoid OOM on low-RAM machines

[gupta-sahil01]

What changes were proposed in this PR?

Root cause. The frontend start script runs ng serve on Node's default V8 heap. Node auto-sizes that limit from available RAM — on an 8 GB machine it's only ~2.2 GB — and ng serve exceeds it during a build, crashing with FATAL ERROR: Reached heap limit — JavaScript heap out of memory. Because the script uses concurrently --kill-others, the crash also tears down the y-websocket process, and the dev server does not recover without a manual restart. The build script already passes --max-old-space-size=8192, so only the dev server was affected — an inconsistency between the two.

Fix. Give ng serve the same heap ceiling the production build already uses, by invoking Node directly on the CLI entry point (the ng wrapper can't forward the flag):

One-line change to frontend/package.json. No effect on developers with 16 GB+ RAM (their default heap was already large enough, which is why this went unnoticed); it simply removes the crash on lower-RAM machines.

Any related issues, documentation, discussions?

• Closes Frontend dev server (ng serve) crashes with "JavaScript heap out of memory" on rebuild for lower-RAM machines #6859

How was this PR tested?

Reproduced and verified on an 8 GB-RAM machine:

• Before: yarn start (→ ng serve) crashed with Reached heap limit — JavaScript heap out of memory, with V8 topping out around ~2040 MB. On this machine it failed on the initial build ("Generating browser application bundles"), not only on incremental rebuilds — so the dev server never even reached a serving state.
• After: with the heap flag, yarn start compiles to "Compiled successfully" and serves localhost:4200, and editing/saving a template no longer crashes it.

No env-var workaround (NODE_OPTIONS=--max-old-space-size=…) is needed anymore — the script carries the limit itself.

Was this PR authored or co-authored using generative AI tooling?

Generated-by: Anthropic Claude (Claude Code)

[github-actions]

Automated Reviewer Suggestions

Based on the git blame history of the changed files, we recommend the following reviewers:

• No candidates found from git blame history.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 78.70%. Comparing base (f521750) to head (05607bb).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff            @@
##               main    #6914   +/-   ##
=========================================
  Coverage     78.70%   78.70%           
  Complexity     3740     3740           
=========================================
  Files          1161     1161           
  Lines         46084    46084           
  Branches       5110     5110           
=========================================
  Hits          36269    36269           
  Misses         8206     8206           
  Partials       1609     1609           

Flag	Coverage Δ		*Carryforward flag
access-control-service	70.00% <ø> (ø)		Carriedforward from f521750
agent-service	76.76% <ø> (ø)		Carriedforward from f521750
amber	71.52% <ø> (ø)		Carriedforward from f521750
computing-unit-managing-service	20.49% <ø> (ø)		Carriedforward from f521750
config-service	66.66% <ø> (ø)		Carriedforward from f521750
file-service	67.21% <ø> (ø)		Carriedforward from f521750
frontend	82.91% <ø> (ø)
notebook-migration-service	78.94% <ø> (ø)		Carriedforward from f521750
pyamber	95.38% <ø> (ø)		Carriedforward from f521750
workflow-compiling-service	55.14% <ø> (ø)		Carriedforward from f521750

*This pull request uses carry forward flags. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[aglinxinyuan]

LGTM!