Allow overriding `build_to`

[natebosch]

This can be safe if the package isn't going to be published.

The main concerns for this are around how we should message it and what type of safety or warnings we can or should provide. My main concern is that its the type of thing that could seem to work fine even when used in an inappropriate way - then some time down the road a builder author could break packages using this and get backed into a corner if users have long-standing dependencies on doing something broken...

[jakemac53]

What if the builder author had to explicitly enable overriding it?

[natebosch]

What if the builder author had to explicitly enable overriding it?

That would definitely make things safer. If we decide later that authors don't need to enable the override we'd end up with a stale config key...

[yury-yufimov]

@natebosch , @jakemac53 , how do think, does it make sense: Allow packages to overwrite BuilderDefinition's from other packages?

Due to performance reasons, in our project we have custom angular and ddc builders. Now them are located in separate package, which starts build without usage of build.yaml files. Another option - to fork angular and build_runner packages. Is there a chance, that overwrites in build.yaml files will be possible?

[jakemac53]

@yury-yufimov we do have some support for overriding build.yaml files from dependencies, you can create a <package-name>.build.yaml file which will override the build.yaml for <package-name>. I haven't used it in a while but afaik it works.

That comes with its own risks (you could get broken if you don't keep it up to date with upstream changes in angular), but I think that is what you are asking for?

Also note that these are only picked up if they exist in the root package, you can't pick up overrides specified by your deps.

[yury-yufimov]

Thanks, @jakemac53 ! We'll take this option into account.

[natebosch]

Another possibility would be to allow a tool to override this to always build to cache and never source.

[jimsimon]

Just stumbled upon @jakemac53's solution above (using <package-name>.build.yaml) and it appears to work. I'm using it for inject, though I might switch to a different DI library since each source file results in two generated files. :-/

[alorenzen]

I'm working with a package (reflectable), which currently specifies build_to: source. I would much rather prefer that it build to the cache.

What's frustrating with the <package-name>.build.yaml approach is that you need to completely copy the entire builder definition, including import, builder_factories, and build_extensions. You can't just override the build_to property and leave everything else as defined by the package author.

Also, I'm currently building another Builder which will run before reflectable. I'd really prefer to override the build_to property in that package instead of only in the root package (aka my clients' packages)

[jakemac53]

It would be nice to be able to override only specific fields for the build.<config>.yaml support as well (which loads different root package configs based on the --config flag).

But it would be somewhat difficult to define exactly how that works - especially when it comes to target definitions etc. It gets pretty complicated if you want to allow modifying the shape of the targets (how do you delete a target?)

[natebosch]

Also, I'm currently building another Builder which will run before reflectable. I'd really prefer to override the build_to property in that package instead of only in the root package (aka my clients' packages)

You're hoping than some builder can override the config of another builder? This in particular seems dangerous to me. There is a very large surface area for things to go wrong with versioning and I'm worried it will impose a level of resistance to any change in a published builder's config. I think the build_to field is probably the one that is the most safe to do, but even there I have hesitations.

I would much rather prefer that it build to the cache.

What is the motivation? Is the imposition of a build system for all uses of the code, not just during generation, a problem?