-
Notifications
You must be signed in to change notification settings - Fork 374
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
language.GenerateResult - allow setting package(default_visibility) #783
Comments
I think this would be a reasonable thing to support. It doesn't make sense for Go, but I could see it being useful for other languages, especially when there are a lot of libraries in a single directory. The breaking change here is too much though. Syntactically, a
|
Also, just brainstorming: maybe this belongs in a language-neutral extension? It could be triggered with a directive. I could see someone writing this at the top of a large subtree in a monorepo:
Then the extension would generate this for every directory in the tree:
|
Both of those ideas sound pretty good. In lieu of that, my recent update to rules_closure's Gazelle was to apply the same behavior from Go's rules to automatically set visibility using the internal directory rule: It seems that the internal/ directory and default_visibility directive serve a similar purpose. I wonder if applying the internal/ directory visibility should also be a language neutral behavior. |
It's hard to come up with a rule that works for everyone. For Go, This may not always be part of the directory either. I used to work on a project that was in |
Sorry to revive an old issue but since it is still open I figured I would. I attempted to proof-of-concept the aforementioned |
I am in favor of a language-neutral directive like |
…build#783) Previously, the implementation of the language/go extension's GenerateRules method only considered args.File, and therefore missed scenarios where another extension (as recommended in the Issue) creates a package(default_visibility = ...)
…#1341) Previously, the implementation of the language/go extension's GenerateRules method only considered args.File, and therefore missed scenarios where another extension (as recommended in the Issue) creates a package(default_visibility = ...)
…iguration via directive (bazelbuild#783) Under a new /bazel/ subdirectory, this language-agnostic extension allows a directive to control the default_visibility templated out to all BUILD.bazel files in or under the directory. This feature is intended to allow large codebases to define hierarchical visibility defaults.
…iguration (bazelbuild#783) Under a new /bazel/ subdirectory, this language-agnostic extension allows a directive to control the default_visibility templated out to all BUILD.bazel files in or under the directory. This feature is intended to allow large codebases to define hierarchical visibility defaults.
…iguration (bazelbuild#783) Under a new /bazel/ subdirectory, this language-agnostic extension allows a directive to control the default_visibility templated out to all BUILD.bazel files in or under the directory. This feature is intended to allow large codebases to define hierarchical visibility defaults.
…iguration (bazelbuild#783) Under a new /bazel/ subdirectory, this language-agnostic extension allows a directive to control the default_visibility templated out to all BUILD.bazel files in or under the directory. This feature is intended to allow large codebases to define hierarchical visibility defaults.
…iguration (#783) (#1343) Under a new /bazel/ subdirectory, this language-agnostic extension allows a directive to control the default_visibility templated out to all BUILD.bazel files in or under the directory. This feature is intended to allow large codebases to define hierarchical visibility defaults.
The closure_js gazelle module produces one rule per source file. Presently, each one of those rules has a visibility set. Setting aside the desirability of having one rule per source file vs one rule per directory, I was interested in extracting visibility management by omitting it on the per-rule basis and setting package(default_visibility) instead when composing a new BUILD file.
There doesn't appear to be any way to set the default_visibility; GenerateResult returns only rules and imports. I propose packing the Rules into a File that is used as a template for the new BUILD file. If that breaking change to the type is unpalatable, I could instead return an additional bit for that, or an additional File type used only for that configuration.
I realize this may not be a core use case and not worth supporting, but I just thought I'd raise it as a possible addition. Thanks
The text was updated successfully, but these errors were encountered: