Bugfix: Why did provideAnimations() cause NG0201 and NG0200 errors i...

Documentation for Sessions

🐛 Bugfix: Why did provideAnimations() cause NG0201 and NG0200 errors i...

Date: 2026-03-24
Time: 17:49:06 UTC
Session: gspace1-264.3
Agent: angular
Confidence: 95%
Status: ✅ Documented

📋 Decision Context

Question:

Why did provideAnimations() cause NG0201 and NG0200 errors in the preview, and how to fix it?

Task: S264: Fix NG0201/NG0200 DomRendererFactory2 provider errors in preview

🎯 Decision Made

Chosen:

Remove provideAnimations() from synthesized appConfig and use noop stubs for @angular/platform-browser/animations subpath entries

Options Considered:

  1. Remove provideAnimations() and use noop stubs (chosen)
  2. Bundle platform-browser + platform-browser/animations as single file (naming conflicts, fragile)
  3. Keep CDN for animations only (re-introduces CDN dependency)
  4. Use provideNoopAnimations() from the noop stub (still loads the conflicting bundle)

💭 Reasoning

Root cause: Angular FESM flat bundles for subpath entries pre-inline parent package code. When esbuild builds platform-browser-animations.mjs, it includes its own copy of DomRendererFactory2 (from @angular/platform-browser). This creates TWO different DomRendererFactory2 classes — one in platform-browser.mjs (used by bootstrapApplication's BROWSER_MODULE_PROVIDERS) and one in platform-browser-animations.mjs (used by provideAnimations). Angular DI uses object identity for tokens, so the animation renderer's dependency on DomRendererFactory2 doesn't match the provider registered by bootstrapApplication. Fix: (1) Remove provideAnimations() since animations are cosmetic for preview. (2) Create noop stubs for the animation subpath entries that export empty functions — satisfies import resolution without duplicating singletons. CSS transitions still work. This is not fixable by adjusting esbuild externals — the FESM format pre-inlines by design.

📁 Files Involved

🔗 Related

Auto-generated by MCP Smart Consolidation