In this scenario the NoopAnimationDriver and NoopAnimationStyleNormalizer would become non-tree-shakable (as they are eagerly referenced). Can we refactor the code to avoid this?

@JeanMeche as a possible solution, we can mimic the provideNoopAnimations() function and call it provideNoopAnimationsAsync(), so that we create one of the engines depending on the function used.

About that, I thought about your suggestion. I doesn't seem applicable to me.

createEngine(), the drivers and the styleNormalizers are part of the lazy loaded bundle so we cannot use providers.

Could you please elaborate a bit on this? My assumption is that having the provideNoopAnimationsAsync() function would allow us to reference the noop-related code there, so we don't have to do it in the provideAnimationsAsync() function. As an option, we can have a callback there that we define there:

      useFactory: (doc: Document, renderer: DomRendererFactory2, zone: NgZone) => {
        // in `provideAnimationsAsync`:
        const getEngine = (m) => m.getEngine();
        // in `provideNoopAnimationsAsync`:
        const getEngine = (m) => m.getNoopEngine();
        return new AsyncAnimationRendererFactory(doc, renderer, zone, type, getEngine);
      },

Sure,

NoopAnimationDriver/NoopAnimationStyleNormalizer are part of the animation module, the module we want to lazy load. By referencing anything of that module outside of it, we will break the code splitting/lazy loading, so we can't define them in the providers.

Currently createEngine() is not imported statically but via the dynamic import of @angular/animations/browser. That why it doesn't break the lazy loading.

I have tried using the animationType parameter to determine which of createEngine or createNoopEngine to call. But both builder don't seem able to infer that animationType is readonly in AsyncAnimationRendererFactory (and it doesn't tree shake the unused one). (demo)

Also, I did try your other solution with the callback, It did not work, likely because the lazy loaded module is passed to the callback function, so the minifer doesn't know what to keep / what to tree-shake.

Can we extract this into a separate PR?

There is definitely some work to do on this.
Pulling the BrowserAnimationBuilder breaks the code splitting because it's in the platform-browser/animations (and not in the async secondary entry we had to created).

I'll remove this from the scope of this PR.

@JeanMeche as a possible solution, we can mimic the provideNoopAnimations() function and call it provideNoopAnimationsAsync(), so that we create one of the engines depending on the function used.

Could you please elaborate a bit on this? My assumption is that having the provideNoopAnimationsAsync() function would allow us to reference the noop-related code there, so we don't have to do it in the provideAnimationsAsync() function. As an option, we can have a callback there that we define there:

      useFactory: (doc: Document, renderer: DomRendererFactory2, zone: NgZone) => {
        // in `provideAnimationsAsync`:
        const getEngine = (m) => m.getEngine();
        // in `provideNoopAnimationsAsync`:
        const getEngine = (m) => m.getNoopEngine();
        return new AsyncAnimationRendererFactory(doc, renderer, zone, type, getEngine);
      },

This is great! 🎉