github.com/ajguerrer/rules_go@v0.20.3/roadmap.rst (about) 1 rules_go and Gazelle roadmap 2 ============================ 3 4 .. _Language Server Protocol: https://langserver.org/ 5 .. _bazel-go-discuss: https://groups.google.com/forum/#!forum/bazel-go-discuss 6 .. _bazelbuild/bazel#1118: https://github.com/bazelbuild/bazel/issues/1118 7 .. _bazelbuild/bazel#4544: https://github.com/bazelbuild/bazel/issues/4544 8 .. _go/build: https://godoc.org/go/build 9 .. _open an issue: https://github.com/bazelbuild/rules_go/issues/new 10 11 This document describes the major rules_go and Gazelle features the Go team is 12 working on and how those features are prioritized. If you have an idea for a 13 feature which is not mentioned here or if you think something should be 14 prioritized differently, please send a message to bazel-go-discuss_, or `open an 15 issue`_. 16 17 Features here are prioritized as P0 (critical), P1 (important), and P2 (nice to 18 have). These priorities are not strict and may change over time. We may work on 19 simpler P2 features before more complicated P0 features. 20 21 Release process 22 --------------- 23 24 P0: Release cadence 25 ~~~~~~~~~~~~~~~~~~~ 26 27 For most of the life of rules_go, we've kept a single master branch with 28 releases tagged on that branch. This practice has kept development simple and 29 fast, but it has imposed more migration work than necessary on developers that 30 just need a new Go SDK or bug fix. 31 32 In the future, the release cadence will be more regular. We will tag major 33 releases from ``master`` near the beginning of each month. Major releases will 34 include new features and upgraded versions of dependencies like gRPC. Of course, 35 dependencies may still be overridden in WORKSPACE. Major releases will have a 36 version number of the form 0.X.0 (where X is the major version number). 37 38 P0: Minor releases 39 ~~~~~~~~~~~~~~~~~~ 40 41 Additionally, we will tag minor releases when needed. Each major release will 42 mark the beginning of a *release branch*. We will cherry-pick fixes for severe 43 bugs and support for new Go SDK versions back to release branches. We will tag 44 minor releases from these branches. Minor releases will have a version number 45 of the form 0.X.Y (where Y is the minor version number). 46 47 Minor releases will not include changes to rules_go dependencies or changes 48 to the API: rules, attributes, and providers will not be changed or removed. 49 50 The last three release branches will be maintained, starting with 0.10. New 51 releases will be announced on `bazel-go-discuss`_. 52 53 Tools 54 ----- 55 56 P0: Integration with tools 57 ~~~~~~~~~~~~~~~~~~~~~~~~~~ 58 59 Standalone tools such as gofmt, goimports, and govet typically assume a standard 60 Go project layout, i.e., that GOPATH and GOROOT are set and imported packages 61 may be found in the directories they point to. These assumptions are not 62 generally valid in a Bazel environment. Tools that collect build metadata with 63 `go/build`_ produce incomplete or inaccurate results since `go/build`_ does not 64 understand Bazel. 65 66 We are developing a new framework for collecting build metadata that will 67 decouple tools from the build system. This framework is important for both Bazel 68 and vgo, which will be the primary Go build system in future releases. Tools 69 using framework will be aware of generated code in Bazel workspaces. 70 71 P0: Integration with editors 72 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 73 74 Editor and IDE support is vitally important. Features like code completion, 75 go-to-definition, and simple refactoring must work. 76 77 The build metadata framework described above is the key part of improving editor 78 support. We will also ensure there is a program that integrates this framework 79 with the `Language Server Protocol`_. This will provide Go-specific 80 functionality to most editors. 81 82 Dependency management 83 --------------------- 84 85 P1: Better external repository support 86 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 87 88 Gazelle will improve support for external repositories in several ways. 89 90 * Gazelle will index libraries in external repositories for dependency 91 resolution. Currently, Gazelle relies on naming conventions when resolving 92 dependencies in external repositories. 93 * Gazelle will be able to add and update repository rules, based on unresolved 94 import paths from sources in the workspace. This will work for direct and 95 transitive dependencies. This should simplify WORKSPACE file maintenance. 96 * Gazelle will import repository rules from more vendoring tools. Currently, 97 Gazelle can import dependencies from dep using ``gazelle update-repos 98 -from_file=Gopkg.lock``. 99 100 P1: Better vendoring support 101 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 102 103 Gazelle will improve support for vendoring in several ways. 104 105 * Test rules will not be generated in vendor by default. Tests frequently pull 106 in dependencies that aren't needed by libraries. Some vendoring tools, such as 107 dep, already prune out test source files from vendored packages. 108 * It will be possible to configure Gazelle to ignore vendor directories in 109 external repositories (via ``go_repository``). 110 * The ``importmap`` attribute will be set by default on go_library rules in 111 vendor. This prevents conflicts when multiple packages with the same import 112 path are linked. 113 114 P2: Overlay repositories 115 ~~~~~~~~~~~~~~~~~~~~~~~~ 116 117 The ``go_repository`` rule retrieves external repositories and generates build 118 files for them using Gazelle at build time. ``go_repository`` doesn't allow 119 manual modifications to generated build files, so if Gazelle does something 120 incorrectly, it's difficult to work around. This has especially been a problem 121 for protos. 122 123 In the future, Gazelle will support "overlay" repositories. Build files may be 124 generated ahead of time using a simple command, modified by hand if needed, then 125 checked in. Repositories may be retrieved using a variant of ``git_repository`` 126 or ``http_archive`` that will copy the pre-generated build files into the 127 correct places. 128 129 Since ``go_repository`` works well for pure Go dependencies, we'll continue to 130 support it, and it will still be the default. However, we will move the 131 definition of ``go_repository`` to Gazelle's repository to reduce 132 coupling between rules_go and Gazelle. 133 134 Coverage 135 -------- 136 137 P0: Bazel code coverage 138 ~~~~~~~~~~~~~~~~~~~~~~~ 139 140 ``bazel coverage`` can be used instead of ``bazel test`` to gather coverage 141 information and present a unified report for multiple tests. 142 143 rules_go already has some support for coverage instrumentation: we can compile 144 binaries that generate coverage data. However, we need Bazel to be able to 145 collect coverage data and present it as a unified report. See 146 `bazelbuild/bazel#1118`_. 147 148 Build 149 ----- 150 151 P1: Static analysis 152 ~~~~~~~~~~~~~~~~~~~ 153 154 Since 1.10, go test runs a subset of vet tests automatically when building 155 tests. We plan to support this and more. Users will be able to run a 156 configurable and extensible set of static analysis checks when building 157 libraries, binaries, and tests. Static analysis may be configured in three 158 places. 159 160 * A global set of checks for all Go packages, configured in WORKSPACE. 161 * A top-down set of checks for all packages a binary or test depends on, 162 configured on the ``go_binary`` or ``go_test`` rule. 163 * A bottom-up set of checks for all packages that depend on a library, 164 configured on the ``go_library`` rule. 165 166 By default, this framework will run the same safe subset of vet checks that go 167 test runs. 168 169 P2: Shared and plugin builds 170 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 171 172 The Go toolchain builds static binaries by default, but it also supports 173 building shared libraries and plugins. rules_go should support these build modes 174 as well. 175 176 Protos 177 ------ 178 179 P1: Correct rules for vendored protos 180 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 181 182 Bazel requires that .proto files import other .proto files using paths relative 183 to a repository root. Unfortunately, this means there's no way for a .proto 184 file in a vendor directory to import another .proto file in a vendor directory. 185 186 The Bazel team is working on adding an attribute to proto_library rules that 187 allows setting a source root (see `bazelbuild/bazel#4544`_). When this attribute 188 is supported in a released version of Bazel, Gazelle will start generating 189 ``proto_library`` rules that use it for proto files in vendor directories. 190 191 Note that by default, Gazelle does not generate proto rules in vendor 192 directories. This probably won't change. 193 194 P2: Remove old proto rules 195 ~~~~~~~~~~~~~~~~~~~~~~~~~~ 196 197 The new proto rules in ``//proto:def.bzl`` have been available for some time. At 198 some point, we'll remove ``//proto:go_proto_library.bzl`` so that we can drop 199 the additional dependencies it requires. 200 201 Rule naming and consolidation 202 ----------------------------- 203 204 P1: Gazelle support for multiple packages per directory 205 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 206 207 Gazelle supports a single Go package per directory, since that's what go build 208 supports. This is a painful limitation for protocol buffers: it's common to 209 store .proto files from different packages in the same directory. In the future, 210 Gazelle will generate separate ``proto_library`` and ``go_proto_library`` rules 211 per package. 212 213 Gazelle will also generate multiple ``go_library`` and ``go_test`` rules when 214 there are sources belonging to multiple packages in the same directory. It's 215 likely that we'll change the naming convention for libraries at this point (no 216 more ``go_default_library``). 217 218 P2: Consolidation of library, binary, and test rules 219 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 220 221 ``gazelle fix`` will squash rules in several new cases: 222 223 * In ``main`` packages with no tests, Gazelle will squash ``go_library`` rules 224 into ``go_binary``. 225 * In packages that only have .proto source files (no .go files other than those 226 generated by the proto compiler), gazelle will squash ``go_library`` rules 227 into ``go_proto_library``. 228 * Internal and external test rules will be squashed into a single ``go_test`` 229 rule. rules_go can now build ``go_test`` rules with both internal and external 230 sources, so separate rules are no longer necessary.