Allow transformers to generate/modify code in packages as a result of whole-code evaluation

[blois]

Right now transformers can only modify code in packages when that package is being transformed, but there are a number of scenarios where the transformation on the package needs to be done with the results of some whole-program analysis.

The specific scenario I'm running into is generating code for Angular in a lazy-loading environment. In a non-lazy environment the generated caches are all injected into the application entry point, but in the lazy-loaded scenario the code needs to be injected into the root of the lazy library.

The issue is that the calculation of what needs to be cached needs to take the entire app into account.

One approach discussed is the 'global transformers' which execute after all package transformers and can modify every package contents.

Marking as critical as it is required for Angular's transformers once lazy-loading is supported.

[munificent]

Issue #14187 has been merged into this issue.

[nex3]

Removed Area-Pub, Pub-Build labels.
Added Area-Pkg, Pkg-Barback labels.

[nex3]

Removed Priority-Critical label.
Added Priority-Medium label.

[sigmundch]

FYI - the latest update is that we'll try to do this as a special transformer that creates a copy-on-write of assets. More details here: https://code.google.com/p/dart/issues/detail?id=18489

[nex3]

We're going to experimentally try an API that allows an application to declare transformers for its dependencies. The syntax will be something like this:

    experimental.global_transformers:
    - some_transformer
    - another_transformer:
        config: value

Each transformer is loaded and applied to each package's asset cascade in order after the normal transformer loading has finished.

[justinfagnani]

Interesting!

Not to look a gift horse in the mouth, but I think that we often need the other direction - that it when a library declares a transformer it needs to transform the entrypoints as well. This is true for libraries that need to register or initialize like custom elements, js-interop, polymer expressions, etc.

[nex3]

I think the way to handle those might be requiring the entrypoint to add a transformer to its global transformer list.

[justinfagnani]

Which is what we currently do. What's unfortunate about that is that it's hard to document. Some transitive dependency uses Polymer and then the app needs to declare the transformer.

[nex3]

If a transitive dependency needs to change code in an application, I think it's reasonable for that application to explicitly opt into that dependency's modifications. Letting them happen silently is a recipe for confusing non-local effects, even if we could deal with the ordering concerns.

[DartBot]

This comment was originally written by @zoechi

---

My package needs a transformer (DI) for examples only and causes troubles (a bug in DI though) in an app that has my package as a dependency because the transformer is executed during pre-compilation and no way to opt out.

#­10 see http://dartbug.com/21777

[nex3]

If you only include the example directory, it shouldn't ever get instantiated for a dependency:

    transformers:
    - di:
      $include: example/**

[DartBot]

This comment was originally written by @zoechi

---

Thanks, that's actually a good idea. Didn't think of it.

[DartBot]

This issue has been moved to dart-archive/barback#39.

[sigurdm]

Blocking: google/reflectable.dart#9

After speaking to Florian and Erik we believe we found a way to generate code only in the entry-point package. So No longer blocking.