feat: add importOverrides as a variant of componentImports

[rpd10]

Goal

Add an importOverrides option to RenderComponentOptions that allows authors to replace specific component imports without replacing the entire imports array. This complements the existing componentImports (full replacement) option.

Motivation

Test authors may want to mock 1-2 heavy child components without enumerating all imports. Today, there are 2 ways to accomplish this:

1. Using componentImports requires listing every import (full replacement via { set: { imports } }). This is fine for components with few imports, but if you have many, it can be cumbersome and unintuitive.
2. Using configureTestBed with raw TestBed.overrideComponent — leaks Angular internals into test code:

await render(MyComponent, {
  configureTestBed: (testBed) => {
    testBed.overrideComponent(MyComponent, {
      remove: { imports: [ChildComponent] },
      add: { imports: [StubChildComponent] },
    });
  },
});

Enhancement

This PR adds some sugar on top of the overrideComponent option to make it easier to override a subset of the component imports:

await render(MyComponent, {
  importOverrides: [
    { replace: ChildComponent, with: StubChildComponent }
  ]
})

[timdeschryver]

Thanks for the PR @rpd10
Do you think this should be preferred over componentImports, and could componentImports be deprecated?

[rpd10]

Thanks Tim - good question. To me, it feels like this matches TestBed's behavior for services that are providedIn: 'root'. If you do nothing, TestBed would inject the real service. You can choose to provide custom mocks/stubs for specific services as needed. If we were building this from the ground up, I would argue that this should be the default behavior.

That being said, I would worry about the migration path for existing consumers and whether it could be automated via ng update. I think the migration would be challenging.

So I think this becomes a question of whether you would want to expose both options and have users/agents reason about which one to use, versus potentially causing heartache during migration. Let me know what your thoughts are.

[timdeschryver]

We're currently also investigating recreating ATL, and a part of this is removing old/deprecated API's.
importOverrides could be added there as well. With that in mind, I don't want to add a migration for it (because it's not that easy, as you've mentioned).

If you want, feel free to also include this change to https://github.com/testing-library/angular-testing-library/blob/main/projects/testing-library/zoneless/src/public_api.ts

We can add a @deprecated to componentImports to warn users, and guide them to the new importOverrides.

[rpd10]

Thanks, added the deprecation notice and hooked this up in the zoneless approach. I didn't see any unit tests for the zoneless API, please let me know if I missed anything.

[timdeschryver]

It's not ideal, but the tests are currently at https://github.com/testing-library/angular-testing-library/blob/main/projects/testing-library/src/tests/zoneless.spec.ts