Stabilize pkg/build for 1.0.0 release

[matanlurey]

re @natebosch in angulardart/angular#758 (comment):

Yeah we hope to have build at 1.0 soon.

It would be a good idea to figure out if any of the existing interface needs to change, or if you want to do any polish around names or exported symbols (latest docs). It's also possible you may want to document if you do/do not want certain classes extended/implemented/mixed in to avoid having to rev to 2.0.0 too quickly.

[natebosch]

Some stuff that we might want before we go 1.0:

• Do we want to wait until we can look at changing Resolver from exposing classes from analyzer to the front_end or some other package?
• Consider either rewriting package:logging or adding a separate interface for the top-level log instance. The oddities in that package give us headaches.

[matanlurey]

from exposing classes from analyzer to the front_end or some other package?

I really don't see this happening in Q1. Do you?

adding a separate interface for the top-level log

SG. There is existing code (Angular, others) that expects a Logger, though. :-/

[jakemac53]

One thing that I have been thinking about here is breaking out the built-in support for analyzer into a separate package. This would have a few benefits:

• We could remove the analyzer dependency from package:build.
• If we wanted to have a summary based resolver today, we would have to take the summary/module builders and move those into package:build_runner (or some other package that build_runner depends on).
• Moving the resolver apis to a separate library allows us to expose a kernel based code resolution api side by side with an analyzer based one.

This would obviously be a breaking change for many consumers, but I think it is probably the best path forward. We could create some apis that are almost as nice as the existing ones hanging off BuildStep, while also enabling things you can't do with the current api:

• BuildStep.inputLibrary could become inputLibraryFor(BuildStep buildStep).
• We could also expose a more general libraryFor(AssetId id) which has been asked for in the past.

@natebosch @kevmoo @matanlurey

[jakemac53]

Also see #710 which should be a part of this

[jakemac53]

And #823 as well

[natebosch]

Moving the resolver apis to a separate library allows us to expose a kernel based code resolution api side by side with an analyzer based one.

We discussed this offline today. This could have some really good benefits but it would be tricky and we would only see the full benefits if we can do this with the Resource API and not need build_runner, or _bazel_codegen to have knowledge of this package. If we need to set up the resolvers manually in those packages like we do today (with full knowledge of build lifecycles) then the benefit drops.

The challenge will be to not leak knowledge of generated code backwards through phases.

[natebosch]

#535 I think will be breaking - we'll want that too

[jakemac53]

Closing this issue, all planned breaking changes are in now.