I'm trying to setup a semi-custom build environment to embed Dart builds in another build system. For this, I basically want the regular build_runner behavior, expect that I need a custom BuildEnvironment and build configuration overrides. At the moment, I have to write my own build scripts and manage the builder applications by hand.
It would be great if we could have an api in build_runner_core that takes a package graph and overridden build configurations and returns everything necessary to generate custom build scripts. Some mechanism to detect when a build script needs to be invalidated would be great too, but I'm not sure how feasible that is when allowing custom build configurations.
I'm happy to work on this if you agree that this is something worth having.
The main downside I see here is that moving it would bring a dependency on code_builder (and transitively built_collection I think) to build_runner_core. I can't think of any reason that's a hard blocker but extra deps here make me nervous since the build_runner and build_runner_core split was mainly about limiting dependencies.
@jakemac53 WDYT?
If dependencies of the core package are a concern, maybe we can expand the apis in package:build_runner/build_script_generate.dart but keep them in that package? As long as they can be used to generate a script with a custom runner import and build configs, I don't need them to be in the core package.
I am not opposed to exposing a package:build_runner/build_script_generate.dart public import to make this functionality available.
Oh, I see we already have that import :). Expanding the apis exposed there also SGTM though in any case.
Most helpful comment
If dependencies of the core package are a concern, maybe we can expand the apis in
package:build_runner/build_script_generate.dartbut keep them in that package? As long as they can be used to generate a script with a custom runner import and build configs, I don't need them to be in the core package.