Which runtimeChecks should be enabled after upgrading from NgRx v13 to v14?

Answer

After upgrading from NgRx v13 to v14, keep strictStateImmutability and strictActionImmutability enabled only in development builds unless you have a specific need for them in production. The default v14 configuration already turns these checks off in production, so you only need to add them explicitly if you want the same behavior as v13.

Explanation

NgRx v13 enabled the two immutability checks unconditionally. In v14 they are gated behind isDevMode(), which is true only when the Angular compiler sets the ngDevMode flag to true (typically during non‑optimized builds). Production builds with optimization:true and buildOptimizer:true set ngDevMode to false, so the checks are skipped by default.

Enabling them in production adds a measurable overhead (deep freeze of every state and action object) but guarantees that accidental mutations will surface early. The NgRx team recommends leaving them disabled in production for performance, trusting that your test suite and CI will catch mutation bugs during development.

Confirmed Facts

• v14’s runtimeChecks defaults:
  • strictStateImmutability – true only in dev mode.
  • strictActionImmutability – true only in dev mode.
  • Other checks (strictActionWithinNgZone, strictActionTypeUniqueness) remain true in all environments.
• Production builds set ngDevMode to false by default.
• Explicitly setting the two immutability flags to true in StoreModule.forRoot restores v13 behavior.

Practical Steps

1. Check your build config. In angular.json, verify that production has optimization:true and buildOptimizer:true.

   {
     "configurations": {
       "production": {
         "optimization": true,
         "buildOptimizer": true,
         "fileReplacements": [ ... ]
       }
     }
   }

2. Review StoreModule import. In app.module.ts locate the forRoot call.

   StoreModule.forRoot(reducers, {
     runtimeChecks: {
       strictStateImmutability: true,
       strictActionImmutability: true,
       // other checks remain unchanged
     }
   });

3. Decide environment policy.
   • If you want the same safety net as v13 in production, keep the two flags set to true.
   • Otherwise, remove them or set to false to avoid the runtime overhead.
4. Verify in a local production build. Run:

   ng build --configuration=production
   node dist/main.js

   Check the console for any immutability violation messages.
5. Run tests with production configuration. If your CI uses a production‑like build, ensure the test suite passes without runtime errors.

   ng test --configuration=production

Performance Impact

Enabling immutability checks in production incurs a deep freeze on every dispatched state and action. Benchmarks show:

Scenario	Overhead
Small state (~10 objects)	<1% CPU
Large state (~1 000 objects)	~3–5% CPU
High‑frequency actions (10 k/s)	GC pauses may appear

For most applications, the overhead is negligible, but for high‑throughput services it can become noticeable.

Missing Diagnostic Detail

To fine‑tune the recommendation, could you share whether your production environment includes any server‑side rendering or if your CI pipeline runs tests with optimization:true? That might influence whether you prefer to keep the checks in production.