In an Angular standalone app, when do you still need importProvidersFrom, and what does it deliberately not give you?

## The problem `importProvidersFrom` solves A standalone Angular app configures itself through `ApplicationConfig.providers` and `provideX()` functions. Many libraries, and much of any older in-house codebase, were written in the NgModule era and expose their services only as an NgModule, often with a `forRoot(config)` static method that returns a **`ModuleWithProviders`**. A standalone app has no `AppModule` to import such a module into. `importProvidersFrom` is the bridge. It is exported from `@angular/core`: ```ts bootstrapApplication(App, { providers: [ importProvidersFrom(LegacyAnalyticsModule.forRoot({ siteId: 'web' })), ], }); ``` ## What it actually does `importProvidersFrom(...sources)` accepts NgModule classes and `ModuleWithProviders` objects. It: 1. **Walks the module graph** — the module itself, and every NgModule it imports, transitively. 2. **Collects every provider** found along the way, including those added by `forRoot()`. 3. **Registers each module class itself**, and arranges for it to be instantiated when the environment injector is created — so a module constructor with side effects still runs. 4. **De-duplicates** modules seen more than once in the graph. 5. Returns the result as **`EnvironmentProviders`**. ## What it deliberately does not give you `importProvidersFrom` is about **providers only**. It ignores a module's `declarations` and `exports`: - The module's components, directives and pipes do **not** become available in any template. To use them, a standalone component lists the NgModule in its own `imports` array — that is a different mechanism, belonging to standalone and NgModule interop. - It does not accept a standalone component. Passing one throws **`NG0800`** in development mode: "Importing providers supports NgModule or ModuleWithProviders but got a standalone component". ## Where the result may go Because it returns `EnvironmentProviders`, the result is only accepted by **environment injectors**: | Location | Accepted? | |---|---| | `ApplicationConfig.providers` | Yes | | A route's `providers` array | Yes — scoped to that route and its children | | A component's or directive's `providers` array | No — **`NG0207`**, "EnvironmentProviders in wrong context" | The same rule applies to `provideRouter()`, `provideHttpClient()` and `provideClientHydration()`, which also return `EnvironmentProviders`. ## When to reach for it — and when not to Use `importProvidersFrom` when **no function-based API exists**: - A third-party library that ships only `SomeModule.forRoot()`. - An in-house module you cannot rewrite yet. Do **not** use it when the library publishes a provider function: - `HttpClientModule` is deprecated; its replacement is `provideHttpClient(withInterceptorsFromDi())` (the extra feature keeps class-based interceptors registered via DI working). - `RouterModule.forRoot(routes)` has `provideRouter(routes)`. - Many third-party libraries now ship their own `provideX()` alongside the module. Wrapping those modules in `importProvidersFrom` works, but it keeps the module-era configuration style and hides which features you actually enabled. A reviewer should read `importProvidersFrom(...)` in `app.config.ts` as a to-do: check whether the library has since shipped a provider function. Library authors expose that function with **`makeEnvironmentProviders([...])`**, which wraps a provider list as `EnvironmentProviders` so consumers cannot misplace it in a component. ## Scoping a bridged module to one route Because a route's `providers` array creates an environment injector for that route and its children, `importProvidersFrom` does not have to go at the root. If only a lazily loaded reports section needs a charting library's services, the bridge can sit on that route: ```ts { path: 'reports', providers: [importProvidersFrom(ChartsModule)], loadComponent: () => import('./reports/reports').then((m) => m.Reports), } ``` Two consequences follow: - The services are created in the route's injector, so they are **separate instances** from any root-level copy of the same providers. - The providers become available when the router activates that route; code outside the route cannot inject them. This is a reasonable way to contain a legacy dependency while the rest of the app moves to provider functions: the module-era code stays behind one route boundary instead of leaking into the root config. ## Common misreadings - "importProvidersFrom makes the module's components usable" — it collects providers only. - "It is how you use a standalone component from a module" — the reverse direction, and it throws `NG0800`. - "It is fine in a component's providers" — `NG0207`. - "It is deprecated" — it is not; it is the supported bridge, just the least preferred option when a function API exists.