I suppose this is problematic for the AOT compiler. The generic type of ModuleWithProviders has to be a simple type reference, as the compiler needs to statically know the NgModule import graph. The type union and dynamic switching as implemented here is therefore not supported.

The way I think this could work is to always return BrowserAnimationsModule here, but using the noop providers:

static forRoot(config: BrowserAnimationsModuleConfig): ModuleWithProviders<BrowserAnimationsModule> {
  return {
    ngModule: BrowserAnimationsModule,
    providers: config.disableAnimations ? BROWSER_NOOP_ANIMATIONS_PROVIDERS : BROWSER_ANIMATIONS_PROVIDERS,
  };
}

This removes the dynamic nature of the import while still providing the appropriate set of providers.

Additionally, it may be worth noting that even the above suggestion would likely not work in View Engine, as it has an additional requirement that even the providers have to be statically known. This restriction has been lifted in Ivy. This can be partially worked around by capturing the BrowserAnimationsModuleConfig as a token of its own and then have useFactory providers for the other tokens that can then inject BrowserAnimationsModuleConfig. But even then you may not be able to do e.g. this:

BrowserAnimationsModule.forRoot({
  disableAnimations: window.matchMedia('(prefers-reduced-motion: reduce)').matches,
})

as the value for disableAnimations is not known statically, which I believe it is required to be in VE. You may want to experiment with this a bit, as I'm not entirely sure if there's a way to make it work in VE.

I was suspecting it could be problematic, but shouldn't it have caused some of the unit tests to fail?
And yeah, the dynamic value won't work for VE in AOT mode, but I figured that it won't be a big deal given that we're in the process of removing it.

In tests only the JIT compiler is used AFAIK. There's packages/compiler-cli/integrationtest but I have never worked with these, but it looks like the tests inside the bazel folder run the AOT compiler using both VE and Ivy.

Specifying what the shape of the object is supposed to be feels redundant since TS already enforces it.

Yeah, I was thinking to provide more specific info in docs, but I guess this would be derived from the function signature?