[testbed-no-implicit-providers] new rule preventing implicit use of dependencies provided in root

[FDIM]

Suggestion for a new rule

{
  "rules": {
    "@angular-eslint/testbed-no-implicit-providers": ["error", { "allow": ["ElementRef", "NgZone", "ChangeDetectorRef", "FooService"]}]
  }
}

There is this issue in angular: angular/angular#25593

Today we are avoiding use of providedIn: 'root' approach, but this is starting to clash with my long term vision of splitting a big project in multiple smaller libraries and eventually being able to adopt micro frontends pattern (when needed).

I'm proposing to solve the issue from another angle, by being OK to use providedIn: 'root' but having a lint rule that checks that no implicit providers are used in a component test (or anything that involves TestBed).

Consider this scenario:

App code

@Directive()
export class InputDirective {
    constructor(
        private inputService: InputService,
        private inputRef: ElementRef<HTMLInputElement>,
        private zone: NgZone,
        private localeService: LocaleService
    ) {
    }
}

Test code

TestBed.configureTestingModule({
    declarations: [
        InputDirective,
    ],
    providers: [
        { provide: LocaleService, useValue: fakeLocaleService },
    ]
}).compileComponents();

I'd expect the lint rule to highlight InputDirective in declarations array stating that not all dependencies are mocked since. This would prevent later code additions from turning this unit test to an integration test. Worst part is misleading error message complaining about a missing dependency that is not even used by the directive itself directly.

A little tricky bit will be to come up with a list of built in providers that do not need/cannot to be mocked and still let users customize it, such as ElementRef.
Another tricky bit is related to HttpClient, we are not using HttpClientTestingModule but some/majority of others do and this rule should still cover these cases and not complain about HttpClient when the relevant testing module is imported.

I'm up to work on a PR making this possible if authors/contributors are onboard with this idea? Thoughts?

Versions

package	version
@angular-eslint/eslint-plugin	X.Y.Z
@typescript-eslint/parser	X.Y.Z
ESLint	X.Y.Z
node	X.Y.Z

# Please run `npx ng version` in your project and paste the full output here:

• I have tried restarting my IDE and the issue persists.
• I have updated to the latest supported version of the packages and checked my ng version output per the instructions given here.

[JamesHenry]

I don't believe this is even possible to create a rule for based on the information available to the linter, but you are welcome to build out a POC to further the discussion

[FDIM]

Cool! I'll see what I can do about this. There should be enough information in typescript to implement such rule, maybe not directly but still, code is there, so I'm hopeful.

[FDIM]

Looks like this may be quite difficult to do. @typescript-eslint package is creating an isolated program when file is being linted, meaning that none of the imports used in a file are resolved. So no type information about, e.g. InputService is known :(
This of course makes sense as it is not needed for most of the cases.

I'll play around a bit more, but do not have much hope anymore :D
Resolving class reference by name from an import path that may be pointing to a barrel file that potentially renames it and only exists in tsconfig.json is not gonna be easy.