Rethinking Dependency Injection

[stalniy]

Is there an existing issue that is already proposing this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe it

The current issue with DI system in Nest.js is:

1. It relies on legacy decorators
2. It relies on emitDecoratorMetadata

These are not just implementation details, they introduce meaningful limitations that may impact NestJS projects in the near future.

The TypeScript team has made it clear that emitting metadata via emitDecoratorMetadata is not aligned with the language's long-term goals (TypeScript non-goals). This metadata emission relies on design-time type information that is tightly coupled with the current TS compiler pipeline and is not replicate in any other build tool (except swc which anyway requires webpack in monorepo).

And that future is getting closer:
Microsoft is actively working on a new Go-based implementation of TypeScript. In their roadmap, they mention that some legacy features will not be supported, though they don’t specify which ones yet. I’ve asked for clarification here, but there's no answer so far.

If emitDecoratorMetadata ends up being one of the dropped features (which seems plausible), that would leave NestJS and any libraries relying on it tied to older, slower build chains, unable to fully leverage modern fast toolchains.

I’m aware of previous issues raised about this:

• inject function #10586
• Support ECMAScript decorators (coming in TypeScript 4.8) #9558

The current stance seems to be that switching to the new TC39 decorators proposal is blocked due to the lack of parameter decorator support. That’s a fair technical limitation but focusing only on that misses the broader picture:

The long-term viability of relying on emitDecoratorMetadata is becoming increasingly questionable.

It’s also worth noting that Angular, the framework that was originally one of the main drivers of TypeScript’s decorator-based patterns, is now moving away from decorators for dependency injection entirely. This should raise a red flag that the decorator+reflection pattern may not be a solid foundation for the future or at least require the second thought.

Describe the solution you'd like

I suggest to replace decorator based dependency injection with inject function. This is the same concept Angular team used to get rid of decorators in their framework.

There are multiple PROS of using inject:

1. Remove reliance on TypeScript’s internal metadata system and legacy decorators
2. Improve compatibility with emerging TypeScript toolchains (like the native Go-based version or esbuild or even nodejs with --strip-types option which in combo with ESM may drastically improve development speed)
3. Reduce the need for complex reflection logic
4. Enable easier integration with non-TypeScript environments (e.g., JavaScript-only codebases)
5. Better DX for class inheritance and for token injection

The code though may look quite similar:

Suggested

class Service {}

class AnotherService {
  constructor(
    private readonly service = inject(Service),
  ) {}
}

Current:

@Injectable()
class Service {}

@Injectable()
class AnotherService {
  constructor(
    private readonly service: Service,
  ) {}
}

Teachability, documentation, adoption, migration strategy

The nice thing about inject function is that it almost reflect the same structure as decorator based approach. Also it may be introduced as alternative/experimental way in parallel to existing decorator based solution, so that projects can migrate iteratively.

Though it will require replacing string based token injection with object based token injection. So, this:

const connectionProvider = {
  provide: 'CONNECTION',
  useFactory: (optionsProvider: MyOptionsProvider, optionalProvider?: string) => {
    const options = optionsProvider.get();
    return new DatabaseConnection(options);
  },
  inject: [...],
}

will become this:

const CONNECTION_TOKEN = new InjectionToken<DatabaseConnection>('CONNECTION')
const connectionProvider = {
  provide: CONNECTION_TOKEN,
  useFactory: (optionsProvider: MyOptionsProvider, optionalProvider?: string) => {
    const options = optionsProvider.get();
    return new DatabaseConnection(options);
  },
  inject: [...],
}

What is the motivation / use case for changing the behavior?

There 2 motivation factors:

1. Ecosystem shift towards faster toolchain. Even nodejs cli has --experimental-strip-types which drastically simplifies build toolchain and helps to develop with typescript without long delays
2. NestJS is a fantastic framework with a vibrant community, and it would be great to see it continue to evolve and future-proof itself.

[micalevisk]

I agree that at some point it will be really important to Nest to not rely on the legacy TS decorators anymore

But I'm not sure if we should design and discuss a solution without taking in count how the parameter decorator feature would look like in the future. Specially because introducing inject() will introduce a lot of maintenance burden as well.

[KostyaTretyak]

It’s also worth noting that Angular, the framework that was originally one of the main drivers of TypeScript’s decorator-based patterns, is now moving away from decorators for dependency injection entirely.

@stalniy , can you provide a link that says Angular is "now moving away from decorators for dependency injection entirely"?

[stalniy]

I agree that at some point it will be really important to Nest to not rely on the legacy TS decorators anymore

But I'm not sure if we should design and discuss a solution without taking in count how the parameter decorator feature would look like in the future. Specially because introducing inject() will introduce a lot of maintenance burden as well.

@micalevisk From my perspective, the main issue isn’t legacy decorators, but rather that the current DI implementation depends on emitDecoratorMetadata option, which seems to go against the direction TypeScript is heading. The TypeScript team appears to be moving toward a types-only approach, delegating code transformation to tools like Babel, esbuild, or SWC.

If emitDecoratorMetadata eventually stops working, we’d likely need to migrate code like this:

@Injectable()
class AnotherService {
  constructor(
    private readonly service: Service,
  ) {}
}

to:

@Injectable()
class AnotherService {
  constructor(
    @Inject(Service) private readonly service: Service,
  ) {}
}

Does that sound right? If so, then I understand why it's important to know how parameter decorator will look like.

Update: the drawback I've encountered is that emitDecoratorMetadata prevents me from using esbuild to build my NestJS app, so I’m currently limited to slower tools like tsc and webpack. It’s unfortunate.

[stalniy]

@KostyaTretyak Angular doesn't say this explicitly somewhere in official documentation. This is my observation following the recent updates, I worked with Angular for the last 4 years. And I can explain how I came to this:

1. Standalone components: reduced the need to define Angular modules, so @NgModule became useless
2. After introduction of signals, they created new decorator free utilities for input, output, viewChild(ren) and contentChild(ren)
3. Latest introduction of inject function made @Injectable(), @Inject, @Optional, @SkipSelf, @Self decorators to be redundant

If you open Angular guide, for the latest version you will not find this decorators in the guide. And if you look deeper into one of the particular topics, you can find this:

So, now there is "RECOMMENDED" way NOT to use decorator utilities and instead rely on simple functions. This will lead every project into obvious direction.

Update: The same about dependency injection -> https://angular.dev/guide/di/creating-injectable-service

[KostyaTretyak]

@stalniy , I think Angular can't completely abandon decorators. Your code in the init message probably won't work:

class Service {}

class AnotherService {
  constructor(
    private readonly service = inject(Service),
  ) {}
}

The inject function must receive a context to correctly insert the appropriate dependencies. As far as I understand, in Angular this code will only work if it has any class-level decorator (for example @Injectable or @Component, see docs: https://angular.dev/guide/di/dependency-injection-context).

Am I wrong?

[stalniy]

@KostyaTretyak it can, so your assumption is not correct. In the latest version of Angular this code is compilable and works fine:

class TestService {
  readonly name = 'Test';
}

@Component({
  selector: 'main-app',
  template: `
    Hello {{ service.name  }}!
  `,
  providers: [TestService]
})
export class AppComponent {
  readonly service = inject(TestService);
}

inject function relies on module scoped variable (hidden in closure) which is changed based on when it's called in the app lifecycle. inject has some restrictions, like it can be used only in sync code, it cannot be used in async functions.

So, since inject was introduced, Angular allows to define services without any additional decorators. Though most people will use @Injectable({ providedIn: 'root' }) to make it simpler to register service in root injector

[KostyaTretyak]

@stalniy , but you gave an example with the @Component decorator (which I just mentioned).

[stalniy]

Neither @Injectable nor @Component create a new dependency injection context. This is just an easy way to explain people when it's safe to use it.

[micalevisk]

in Nestjs, your example

  constructor(
    private readonly service = inject(Service),
  ) {}

does make sense to me (unless there is some sort of code transformation where that default assignment is erased). What about optional providers injected using constructor-based injection? 🤔

[KostyaTretyak]

@stalniy, please provide an example that does not use a class-level decorator and does not use providedIn.