bazel/bazel-skylib
2
0
Fork 0
mirror of https://github.com/bazelbuild/bazel-skylib synced 2024-11-28 08:43:51 +00:00
Code Issues Releases Activity
bazel-skylib/gazelle/MODULE.bazel

22 lines
858 B
Plaintext
Raw Normal View History

Add the gazelle plugin to the distribution (#400) * Add the gazelle plugin to the distribution To avoid everyone needing to take a dep on `rules_go`, we do the following: 1. Regular Bazel users need to load `bazel_skylib_gazelle_plugin_workspace` and call that, and then `bazel_skylib_gazelle_plugin_setup` 2. `bzlmod` users need do nothing, but we now include the `rules_go` dep in the `MODULE.bazel` shipped in the release. This is fine, because `bzlmod` will lazily load dependencies. * Run buildifier * Add docstring to `gazelle_setup.bzl` * Move "internal only" marker * Make @com_github_bazelbuild_buildtools visible in the deployed module * Respond to review comments * Move plugin to a nested workspace * Run buildifier * Restore the module declaration from `main` * Bump versions of rules_go and gazelle used in the top-level module to match the ones in gazelle * Respond to review comments and add gazelle to ignored directories so //... works as expected * Add missing descriptor for stardoc * Move gazelle hints into workspace files
2022-11-07 10:25:38 +00:00
module(
name = "bazel_skylib_gazelle_plugin",
Add gazelle plugin to CI and distribution mechanism (#424) After #400, the gazelle plugin has been cleanly separated out into its own bazel workspace, which will soon finally allow us to mark it stable. But this means: * we need to change our bazelci config to explicitly build and test it, since `bazel build //...` no longer includes the plugin; * we need to add proper distribution rules for it; * we need to update release instructions, since now we will have two distribution tarballs
2023-01-20 21:48:10 +00:00
# Keep in sync with @bazel_skylib//:MODULE.bazel and @bazel_skylib//:version.bzl
prepare for release 1.5.0 (#472)
2023-11-05 16:16:45 +00:00
version = "1.5.0",
Add gazelle plugin to CI and distribution mechanism (#424) After #400, the gazelle plugin has been cleanly separated out into its own bazel workspace, which will soon finally allow us to mark it stable. But this means: * we need to change our bazelci config to explicitly build and test it, since `bazel build //...` no longer includes the plugin; * we need to add proper distribution rules for it; * we need to update release instructions, since now we will have two distribution tarballs
2023-01-20 21:48:10 +00:00
compatibility_level = 1,
Add the gazelle plugin to the distribution (#400) * Add the gazelle plugin to the distribution To avoid everyone needing to take a dep on `rules_go`, we do the following: 1. Regular Bazel users need to load `bazel_skylib_gazelle_plugin_workspace` and call that, and then `bazel_skylib_gazelle_plugin_setup` 2. `bzlmod` users need do nothing, but we now include the `rules_go` dep in the `MODULE.bazel` shipped in the release. This is fine, because `bzlmod` will lazily load dependencies. * Run buildifier * Add docstring to `gazelle_setup.bzl` * Move "internal only" marker * Make @com_github_bazelbuild_buildtools visible in the deployed module * Respond to review comments * Move plugin to a nested workspace * Run buildifier * Restore the module declaration from `main` * Bump versions of rules_go and gazelle used in the top-level module to match the ones in gazelle * Respond to review comments and add gazelle to ignored directories so //... works as expected * Add missing descriptor for stardoc * Move gazelle hints into workspace files
2022-11-07 10:25:38 +00:00
)
Add gazelle plugin to CI and distribution mechanism (#424) After #400, the gazelle plugin has been cleanly separated out into its own bazel workspace, which will soon finally allow us to mark it stable. But this means: * we need to change our bazelci config to explicitly build and test it, since `bazel build //...` no longer includes the plugin; * we need to add proper distribution rules for it; * we need to update release instructions, since now we will have two distribution tarballs
2023-01-20 21:48:10 +00:00
# Keep in sync with @bazel_skylib//:MODULE.bazel and @bazel_skylib//:version.bzl
Update changelog and version for release 1.4.2 (#451)
2023-05-31 19:24:07 +00:00
bazel_dep(name = "bazel_skylib", version = "1.4.2")
Update rules_go and gazelle deps to be compatible with --incompatible_disable_starlark_host_transitions (#433) Partially addresses --incompatible_disable_starlark_host_transitions
2023-02-09 05:09:22 +00:00
bazel_dep(name = "gazelle", version = "0.29.0", repo_name = "bazel_gazelle")
Upgrade rules_go (#460)
2023-11-02 14:38:36 +00:00
bazel_dep(name = "rules_go", version = "0.41.0", repo_name = "io_bazel_rules_go")
Add the gazelle plugin to the distribution (#400) * Add the gazelle plugin to the distribution To avoid everyone needing to take a dep on `rules_go`, we do the following: 1. Regular Bazel users need to load `bazel_skylib_gazelle_plugin_workspace` and call that, and then `bazel_skylib_gazelle_plugin_setup` 2. `bzlmod` users need do nothing, but we now include the `rules_go` dep in the `MODULE.bazel` shipped in the release. This is fine, because `bzlmod` will lazily load dependencies. * Run buildifier * Add docstring to `gazelle_setup.bzl` * Move "internal only" marker * Make @com_github_bazelbuild_buildtools visible in the deployed module * Respond to review comments * Move plugin to a nested workspace * Run buildifier * Restore the module declaration from `main` * Bump versions of rules_go and gazelle used in the top-level module to match the ones in gazelle * Respond to review comments and add gazelle to ignored directories so //... works as expected * Add missing descriptor for stardoc * Move gazelle hints into workspace files
2022-11-07 10:25:38 +00:00
Stop registering a Go SDK in the Gazelle submodule (#411) * Do not register a Go toolchain for ourselves This module can be used as a transitive dep, and so we want to avoid forcing users to futz with their SDKs. * Add a small comment
2022-11-16 18:29:32 +00:00
# `rules_go` will register a toolchain for us if the user doesn't do so
Add the gazelle plugin to the distribution (#400) * Add the gazelle plugin to the distribution To avoid everyone needing to take a dep on `rules_go`, we do the following: 1. Regular Bazel users need to load `bazel_skylib_gazelle_plugin_workspace` and call that, and then `bazel_skylib_gazelle_plugin_setup` 2. `bzlmod` users need do nothing, but we now include the `rules_go` dep in the `MODULE.bazel` shipped in the release. This is fine, because `bzlmod` will lazily load dependencies. * Run buildifier * Add docstring to `gazelle_setup.bzl` * Move "internal only" marker * Make @com_github_bazelbuild_buildtools visible in the deployed module * Respond to review comments * Move plugin to a nested workspace * Run buildifier * Restore the module declaration from `main` * Bump versions of rules_go and gazelle used in the top-level module to match the ones in gazelle * Respond to review comments and add gazelle to ignored directories so //... works as expected * Add missing descriptor for stardoc * Move gazelle hints into workspace files
2022-11-07 10:25:38 +00:00
go_deps = use_extension("@bazel_gazelle//:extensions.bzl", "go_deps")
go_deps.module(
path = "github.com/bazelbuild/buildtools",
sum = "h1:fmdo+fvvWlhldUcqkhAMpKndSxMN3vH5l7yow5cEaiQ=",
version = "v0.0.0-20220531122519-a43aed7014c8",
)
use_repo(go_deps, "com_github_bazelbuild_buildtools")
Copy permalink