@pkozlowski-opensource this is a use-case that might be tricky to support with Standalone Components (i.e. the TestBed.overrideProvider calls) without TestBed.configureTestingModule calls, since TestBed doesn't have enough information at the right time to make the necessary provider overrides. I think we can have a nice error message to let users know and suggest an alternative solution to use TestBed.overrideModule(ComponentDependenciesModule, {set: {providers: [ ... ]}}) instead, i.e. reference a type that declares that provider. So the test code will look like this:

// In this case the `TestBed.configureTestingModule ` is *not* required,
// TestBed knows where to find a class that declares that provider.
TestBed.overrideModule(
  ComponentDependenciesModule,
  {set: {providers: [ {provide: A, useValue: 'Overridden A' } ]}}
);

const fixture = TestBed.createComponent(MyStandaloneComp);

The real question for me here is this: should we be able to override providers of sth that got imported into a standalone module? Or should we rather consider it as a "black box" and allow people to override "imports" as the whole - but not pick into individual imports?

TBD

should we be able to override providers of sth that got imported into a standalone module?

I would say yes, since NgModules worked this way. You could override providers deep in dependencies. The override operation is an explicit piercing of any encapsulation.

Yeah, in cases when standalone types are used as dependencies (imported somewhere in an NgModule), but a non-standalone component is used to create a testing fixture (via TestBed.createComponent) - provider overrides would work correctly after this PR. However there are still sharp edges with provider overrides when a standalone component is used to create a fixture - I hope to improve this in a followup PR.

should we be able to override providers of sth that got imported into a standalone module?

I would say yes, since NgModules worked this way. You could override providers deep in dependencies. The override operation is an explicit piercing of any encapsulation.

Nit: should we rename this function to applyProviderOverridesToScope or something? Since it's not specifically targreting NgModules?

We can definitely do this in a cleanup.

Good idea, I will create a followup cleanup PR 👍