Hello,

inject() is now the official recommended way to inject dependencies in Angular, and the prefer-inject rule is in the recommended set of Angular ESLint since v20.

While this new syntax has been done for some reasons I will not expand here, there is one setback: inject() must be used in an "injection context". There is 2 main issues with this:

• the concept of "injection context" is obscure for beginners (and not well documented enough)
• if outside an injection context, compilation is fine but a runtime error happens, which I see as a major setback in Angular and TypeScript philosophy (it is much more difficult to debug, and all other consequences)

The 2 main errors developers do:

• using inject() in ngOnInit() or other methods
• using inject() in a constructor or field initializer, but inside a callback where the injection context is lost (for example inside the callback of an Observable operator or a Promise)

This rule aims to fix all these problems by checking inject() is used only in allowed places.

It was quite a challenge, but I think I manage to take into account all places where the injection context is available:

• Component / Directive / Pipe / Injectable / NgModule field initializers
• Component / Directive / Pipe / Injectable / NgModule constructors
• special contexts (mainly guards, resolvers and interceptors), both in new function syntax and legacy class syntax
• options of a route (inline guard, inline resolver, and other route properties accepting a callback)
• factories of an InjectionToken, a provider or an Injectable
• in explicit runInInjectionContext()
• in some application providers (like provideAppInitializer(), providePlatformInitializer(), provideEnvironmentInitializer(), and view transitions options)
• in custom injectable functions where injection context is asserted via assertInInjectionContext()
• but never in a nested callback or after an await (which is equivalent to be in a .then() callback)

This list was possible by the combination of:

• the official injection context documentation
• the official inject() documentation
• the official runInInjectionContext() documentation
• this comment of the issue and my own research in the official documentation and in the GitHub releases notes of Angular.

About rule name and future-proof consistency: I hesitated between no-inject-outside-di-context and no-injection-outside-di-context. Indeed, this PR could easily be the base of other similar rules, as other functions like effect() or toSignal() require an injection context. But note that the scenario is not exactly the same for 2 reasons:

• these functions accept an injector as a parameter if outside an injection context (which inject() does not)
• the purpose is not the same: these functions require an injection context mainly to be able to be destroyed properly (while inject() requires an injection context by its own nature and purpose)

So it would be more a generalization of #2803, and the future other rule could be called no-implicit-injector or no-implicit-injection-context.

Also, while I tried be as generic as possible, part of this rule code needed to be hard-coded (special functions names for example). While it will not change every day, I volunteer for maintaining this rule (my work allows me to keep a close eye on Angular releases and details).

Thanks to @JamesHenry for the amazing work, and to @rznn7 for #2803 which served as a model and base for this new rule.

Fixes #2300