Stop Rebuilding the Same Angular Service in Every Module

Singleton Services for Cleaner Angular Apps

As an Angular app grows, dependency management gets messy fast — services get re-instantiated where they shouldn't be, initialization logic scatters across modules, and nobody's quite sure which part of the app owns which service. A shared core module built around singleton services fixes this directly: fewer duplicate instances, cleaner dependency injection, and a predictable place for startup logic to live.

What the Core Module Actually Does

The core module is a single, centralized home for services and utility functions used across the app — nothing else. Unlike feature modules, which hold components and directives, the core module holds only services. Keeping that boundary strict is what makes the pattern useful: anyone looking for "where does this app-wide service live" has exactly one place to check.

The main payoff is singleton services — instantiated once, shared everywhere. That means no redundant initialization wasting resources, and it means components can share state and data cleanly through the service instead of passing data around with events and callbacks.

Setting it up comes down to two things: defining the module, and configuring the providers. Generate the core module with the Angular CLI:

ng generate module core --flat --module=app

The --flat flag puts the module in the project root instead of its own folder, which keeps the structure simple and the module easy to find.

From there, generate each service with ng generate service core/my-service and list it under the providers property in the core module's @NgModule decorator. That's what guarantees the service is instantiated as a singleton and available for injection anywhere in the app.

One rule matters more than the rest: the core module should never declare components, directives, or pipes — services only. That boundary is what prevents conflicts and duplication with feature modules trying to declare the same kind of thing. Finally, import the core module into the root module (app.module.ts) so its services are available application-wide.

The payoff compounds as the app grows. New services slot into the existing core module without touching what's already there, and the clean split between core and feature modules makes it easier for a team to work in parallel without stepping on each other's code.

Conclusion

A shared core module with singleton services is a small structural decision that prevents a specific, recurring class of Angular bugs — duplicate service instances, scattered initialization, unclear ownership. It costs almost nothing to set up early and gets expensive to retrofit later, which is exactly why it's worth doing from the start of a project, not after the dependency graph is already tangled.

Tyrone Showers