# Use Angular standalone components without NgModules

- Status: accepted
- Date: 2026-04-26

## Context and Problem Statement

Angular historically required all components, directives, and pipes to be declared inside NgModules. Angular 14 introduced standalone components as an opt-in. Angular 17+ made them the recommended default and they are required for the esbuild-based application builder. How should the application be structured?

## Considered Options

- Standalone components (no NgModules)
- NgModule-based architecture

## Decision Outcome

Chosen option: "Standalone components (no NgModules)", because they are the Angular-recommended default since v17, provide explicit per-component dependency declarations, and are required for the esbuild application builder.

### Positive Consequences

- Each component explicitly declares its own `imports` — dependencies are visible and not hidden in a shared module.
- Better tree-shaking: unused imports in one component don't affect others.
- Aligns with Angular's long-term direction.

### Negative Consequences

- Slightly more verbose component decorators — each component lists its own imports rather than inheriting from a module.

## Pros and Cons of the Options

### Standalone components (no NgModules)

- Good, because explicit dependency declarations per component.
- Good, because required for the esbuild application builder.
- Good, because Angular-recommended default since v17.
- Bad, because more verbose decorators.

### NgModule-based architecture

- Good, because familiar pattern for developers coming from Angular < 14.
- Bad, because deprecated direction; incompatible with the modern application builder.
- Bad, because shared module patterns hide dependencies.