Currently, the web_resources() rule merges all its transitive dependencies into a single directory and fails if there is a merge conflict. However, this merge is done at the top-level when a consumer wants the full directory. This directory is not generated for every web_resources() rule, only the last one. This means that if there is a path conflict, that won't be detected until the very end of the compilation.
This is particularly annoying if a developer created a shared component and checked in a bad web_resources() rule (depending on some other web_resources() targets which caused a path conflict). They might be able to pass tests and submit their change. Only once a web_resources_devserver() or other consumer actually used the directory would the error be found. If there is an organizational boundary between the shared component developer and the prerender_page() where it is used, this could be quite annoying to find and fix.
We need to find a way to validate that the web_resources() rule does not have conflicts as part of its own compilation, even before it is actually used. Bazel doesn't have great support for validating builds at the moment, but mangling the dependencies in a non-intuitive way could possibly trigger a full merge to be done before allowing downstream web_resources() targets to depend on a broken target.
Currently, the
web_resources()rule merges all its transitive dependencies into a single directory and fails if there is a merge conflict. However, this merge is done at the top-level when a consumer wants the full directory. This directory is not generated for everyweb_resources()rule, only the last one. This means that if there is a path conflict, that won't be detected until the very end of the compilation.This is particularly annoying if a developer created a shared component and checked in a bad
web_resources()rule (depending on some otherweb_resources()targets which caused a path conflict). They might be able to pass tests and submit their change. Only once aweb_resources_devserver()or other consumer actually used the directory would the error be found. If there is an organizational boundary between the shared component developer and theprerender_page()where it is used, this could be quite annoying to find and fix.We need to find a way to validate that the
web_resources()rule does not have conflicts as part of its own compilation, even before it is actually used. Bazel doesn't have great support for validating builds at the moment, but mangling the dependencies in a non-intuitive way could possibly trigger a full merge to be done before allowing downstreamweb_resources()targets to depend on a broken target.