Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: separate dev_builders entry for configuring builders only used for dev tasks #3113

Open
ekweible opened this issue May 25, 2021 · 1 comment

Comments

@ekweible
Copy link

The build.yaml file is intended to be published as a part of any package that has one. By doing so, build_runner knows how to build each dependency. Because of this, any builder applied to a package via its public build.yaml is effectively a part of its public API, meaning that those builders should be real dependencies and not dev_dependencies.

For builders that only read/write non-public files (e.g. tests), you likely don't want to make them real dependencies, and it shouldn't be necessary since the builder config should only impact the root package and not any consumers. But, if the builder config is included in build.yaml, it will be.

One workaround for this is to place dev-only builder config in a <package_name>.build.yaml file, where <package_name> is the name of the root package. This config is still auto-applied by build_runner like build.yaml, but isn't included in the "public API".

However, a better solution might be to support a separate dev_builders entry under each build target. When running build_runner in the same package, the dev_builders entries would be merged with the builders entries. When parsing build.yamls from dependencies, dev_builders entries would be ignored.


The original impetus for creating this issue turned out to be because of a known issue causing a builder to be created when it shouldn't be (#2191), but this feature may still be valuable on its own.

@jakemac53
Copy link
Contributor

Interesting idea, not sure why I never responded here 🤣 . Are you still interested in this @ekweible ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants