Angular Standalone Migration: A Deep Dive into Dependency Injection Pitfalls & Best Practices

🚀 Upgrading a large Angular application from v17 to v21 isn’t just a version bump — it was an architectural wake-up call.

One of the biggest shifts I had to tackle was moving the app to a fully standalone architecture. That change alone forced me to pause and ask an important question:

👉 “Do we actually understand how dependency injection is working in our app?”

As I dug deeper, I realized many DI patterns in the codebase worked by coincidence, not by design. They had survived for years thanks to NgModules— but in a standalone world, they suddenly felt fragile, confusing, or outright wrong.

🔍 In this article, I’ll walk through real cases from a production app:

• what the original code looked like


• why it worked earlier


• where it breaks or misleads in standalone Angular


• and how to fix it cleanly and correctly
  

If you’re upgrading an existing Angular app or refactoring legacy DI patterns — this guide is for you.

⚠️ The migration is still ongoing — I’ll be publishing more articles as I continue the upgrade.

1. From NgModule.providers to providedIn: 'root'

❌ Legacy pattern (NgModule era)

This worked because:

• The module owned the DI scope


• Services were implicitly singleton within the module

✅ Standalone replacement

Why this is correct

• 
  providedIn: 'root' replaces module-level providers


• Singleton behavior is preserved


• Tree-shakable and future-proof

Rule:

If a service was previously in Module.providers, it should almost always move to providedIn: 'root'.

2. Services in bootstrapApplication — what really belongs there?

❌ What I initially had in main.ts

This works, but it’s not a correct standalone design.

✅ What SHOULD be in main.ts

What bootstrapApplication is for:

✅ Framework overrides (ErrorHandler, TitleStrategy, etc.)

✅ Router setup & strategies

✅ HttpClient + interceptors

✅ App-wide configuration tokens

✅ Platform / framework modules

✅ Legacy services you cannot modify

What it is NOT for:

❌ API / CRUD services

❌ Business/domain services

❌ Feature logic

❌ Component state services

3. Services with Subject / BehaviorSubject: Root or not?

My use case

• App loads a master API


• Stores success/error messages in a BehaviorSubject


• Multiple components read from it

❌ Legacy misuse

This creates:

• Multiple instances


• Multiple subscriptions


• Hidden bugs

✅ Correct design

If a service stores state that many parts of the app use, it should live at the root so everyone gets the same data.

4. Services in component providers+ providedIn: 'root'

Yes, Angular allows this — but it’s dangerous.

Result

• Component gets a new instance


• App gets a different instance

⚠️ For API, auth, socket, or state services — this is almost always a bug.

5. Pipes (DatePipe& custom pipes) in providers

❌ What I found

✅ Correct usage

Or simply inject without providing:

Custom pipes used only in .ts?

👉 They should not be pipes — convert them to:

• utility functions


• or services

6. Components injected into other components (⚠️ critical)

❌ Legacy anti-pattern I found

This creates a ghost component instance:

• Not rendered


• Not part of the DOM


• Not change-detected

✅ Correct approaches

Option 1: @ViewChild

Option 2: Shared service (recommended)

Components should NEVER appear in providers.

7. .spec.ts files and providers — is that okay?

Yes — tests have their own DI world.

This:

• Is test-scoped


• Does not affect runtime DI


• Is perfectly valid

No changes needed during migration.

8. GlobalErrorHandler — the exception that belongs in main.ts

Why it must stay in main.ts and not part of a component?

🧠 Angular itself uses ErrorHandler, so it must be registered during app bootstrap, before any component is created.

🌍 Error handling must be truly global — errors can occur outside component lifecycles and feature scopes.

🏗️ Components manage UI, not framework behavior, and global error handling is part of Angular’s core infrastructure.

⚠️ Providing it in components can create multiple instances, leading to inconsistent or missed error handling.

Final Takeaways

• Standalone Angular removes NgModules, not DI rules


• 
  providedIn: 'root' replaces most module-level providers


• 
  bootstrapApplication is for framework wiring only


• Components must never be used as services


• Stateful services belong at root unless isolation is intentional

🚀 If you’re migrating to standalone Angular or have run into DI-related challenges, feel free to share your questions or experiences in the comments — I’d love to discuss them 🙂