{"id":13810724,"url":"https://github.com/bazelbuild/rules_scala","last_synced_at":"2025-04-14T05:17:56.998Z","repository":{"id":37470610,"uuid":"51930379","full_name":"bazelbuild/rules_scala","owner":"bazelbuild","description":"Scala rules for Bazel","archived":false,"fork":false,"pushed_at":"2025-03-26T19:42:05.000Z","size":4556,"stargazers_count":370,"open_issues_count":264,"forks_count":286,"subscribers_count":37,"default_branch":"master","last_synced_at":"2025-04-14T05:17:01.718Z","etag":null,"topics":["bazel","bazel-rules","scala","scalatest"],"latest_commit_sha":null,"homepage":null,"language":"Starlark","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/bazelbuild.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE.txt","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":"CODEOWNERS","security":null,"support":null,"governance":"Governance.md","roadmap":null,"authors":"AUTHORS","dei":null,"publiccode":null,"codemeta":null}},"created_at":"2016-02-17T14:57:24.000Z","updated_at":"2025-04-07T14:28:30.000Z","dependencies_parsed_at":"2023-02-19T08:46:19.465Z","dependency_job_id":"3ae684aa-3516-4e02-89fa-a9a2e265385d","html_url":"https://github.com/bazelbuild/rules_scala","commit_stats":null,"previous_names":[],"tags_count":22,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/bazelbuild%2Frules_scala","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/bazelbuild%2Frules_scala/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/bazelbuild%2Frules_scala/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/bazelbuild%2Frules_scala/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/bazelbuild","download_url":"https://codeload.github.com/bazelbuild/rules_scala/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":248824694,"owners_count":21167345,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["bazel","bazel-rules","scala","scalatest"],"created_at":"2024-08-04T03:00:24.200Z","updated_at":"2025-04-14T05:17:56.393Z","avatar_url":"https://github.com/bazelbuild.png","language":"Starlark","readme":"# Scala Rules for Bazel\n\n[![Build status](https://badge.buildkite.com/90ce5244556df74db805a3c24a703fb87458396f9e1ddd687e.svg?branch=master)](https://buildkite.com/bazel/scala-rules-scala-postsubmit)\n\n## Where to get help\n\n- [#scala @ Bazel Slack](https://bazelbuild.slack.com/archives/CDCKJ2KFZ)\n- [Google group](https://groups.google.com/u/1/g/bazel-scala)\n- [Gitter chat](https://gitter.im/bazelbuild_rules_scala/Lobby)\n\n## Overview\n\n[Bazel](https://bazel.build/) is a tool for building and testing software and can handle large,\nmulti-language projects at scale.\n\nThis project defines core build rules for [Scala](https://www.scala-lang.org/) that can be used to build, test, and package Scala projects.\n\n## Rules\n\n- [scala_library](./docs/scala_library.md)\n- [scala_macro_library](./docs/scala_macro_library.md)\n- [scala_binary](./docs/scala_binary.md)\n- [scala_test](./docs/scala_test.md)\n- [scala_repl](./docs/scala_repl.md)\n- [scala_library_suite](./docs/scala_library_suite.md)\n- [scala_test_suite](./docs/scala_test_suite.md)\n- [thrift_library](./docs/thrift_library.md)\n- [scala_proto_library](./docs/scala_proto_library.md)\n- [scala_toolchain](./docs/scala_toolchain.md)\n- [scala_import](./docs/scala_import.md)\n- [scala_doc](./docs/scala_doc.md)\n\n## Getting started\n\n[Install Bazel][], preferably using the [Bazelisk][] wrapper. See the\n[compatible Bazel versions](#compatible-bazel-versions) section to select a suitable\nBazel version.\n\n[Install Bazel]: https://docs.bazel.build/versions/master/install.html\n[Bazelisk]: https://docs.bazel.build/versions/master/install.html\n\nAdd the following configuration snippet to your `WORKSPACE` file and update the\nrelease `\u003cVERSION\u003e` and its `\u003cSHA256\u003e` as specified on the [rules_scala releases\npage][releases]. This snippet is designed to ensure that users pick up the\ncorrect order of dependencies for `rules_scala`. If you want to override any of\nthe following dependency versions, make sure to `load()` them before calling\n`rules_scala_dependencies()`.\n\n[releases]: https://github.com/bazelbuild/rules_scala/releases\n\n```py\n# WORKSPACE\nload(\"@bazel_tools//tools/build_defs/repo:http.bzl\", \"http_archive\")\n\n# See https://github.com/bazelbuild/rules_scala/releases for up to date version\n# information, including `\u003cVERSION\u003e` and `\u003cSHA256\u003e` values.\nhttp_archive(\n    name = \"rules_scala\",  # Can be \"io_bazel_rules_scala\" if you still need it.\n    sha256 = \"\u003cSHA256\u003e\",\n    strip_prefix = \"rules_scala-\u003cVERSION\u003e\",\n    url = \"https://github.com/bazelbuild/rules_scala/releases/download/\u003cVERSION\u003e/rules_scala-\u003cVERSION\u003e.tar.gz\",\n)\n\nload(\"@rules_scala//scala:deps.bzl\", \"rules_scala_dependencies\")\n\nrules_scala_dependencies()\n\n# Only include the next two statements if using\n# `--incompatible_enable_proto_toolchain_resolution`.\n# See the \"Using a precompiled protocol compiler\" section below.\nload(\"@platforms//host:extension.bzl\", \"host_platform_repo\")\n\n# Instantiates the `@host_platform` repo to work around:\n# - https://github.com/bazelbuild/bazel/issues/22558\nhost_platform_repo(name = \"host_platform\")\n\n# This is optional, but register this toolchain before any others. Requires\n# invoking the `scala_protoc_toolchains` repo rule, but is safe to include even\n# `--incompatible_enable_proto_toolchain_resolution` is `False`.\n# See the \"Using a precompiled protocol compiler\" section below.\nregister_toolchains(\"@rules_scala_protoc_toolchains//...:all\")\n\nload(\"@rules_java//java:rules_java_deps.bzl\", \"rules_java_dependencies\")\n\nrules_java_dependencies()\n\nload(\"@bazel_skylib//:workspace.bzl\", \"bazel_skylib_workspace\")\n\nbazel_skylib_workspace()\n\n# If you need a specific `rules_python` version, specify it here.\n# Otherwise you may get the version defined in the `com_google_protobuf` repo.\nhttp_archive(\n    name = \"rules_python\",\n    sha256 = \"2ef40fdcd797e07f0b6abda446d1d84e2d9570d234fddf8fcd2aa262da852d1c\",\n    strip_prefix = \"rules_python-1.2.0\",\n    url = \"https://github.com/bazelbuild/rules_python/releases/download/1.2.0/rules_python-1.2.0.tar.gz\",\n)\n\nload(\"@rules_python//python:repositories.bzl\", \"py_repositories\")\n\npy_repositories()\n\n# Note that `rules_java` 8.x suggests loading `protobuf_deps()` after\n# `rules_java_dependencies` and before `rules_java_toolchains()`:\n# - https://github.com/bazelbuild/rules_java/releases/tag/8.9.0\n#\n# `rules_java` 7.x also works with this ordering.\nload(\"@com_google_protobuf//:protobuf_deps.bzl\", \"protobuf_deps\")\n\nprotobuf_deps()\n\nload(\"@rules_java//java:repositories.bzl\", \"rules_java_toolchains\")\n\nrules_java_toolchains()\n\nload(\"@rules_proto//proto:repositories.bzl\", \"rules_proto_dependencies\")\n\nrules_proto_dependencies()\n\nload(\"@rules_proto//proto:setup.bzl\", \"rules_proto_setup\")\n\nrules_proto_setup()\n\nload(\"@rules_proto//proto:toolchains.bzl\", \"rules_proto_toolchains\")\n\nrules_proto_toolchains()\n\n# Include this after loading `platforms`, `com_google_protobuf`, and\n# `rules_proto` to enable the `//protoc` precompiled protocol compiler\n# toolchains. See the \"Using a precompiled protocol compiler\" section below.\nload(\"@rules_scala//protoc:toolchains.bzl\", \"scala_protoc_toolchains\")\n\n# This name can be anything, but we recommend `rules_scala_protoc_toolchains`.\nscala_protoc_toolchains(name = \"rules_scala_protoc_toolchains\")\n\nload(\"@rules_scala//:scala_config.bzl\", \"scala_config\")\n\n# Stores the selected Scala version and other configuration parameters.\n#\n# 2.12 is the default version. Use other versions by passing them explicitly:\n#\n#   scala_config(scala_version = \"2.13.16\")\n#\n# You may define your own custom toolchain using Maven artifact dependencies\n# configured by your `WORKSPACE` file, imported using an external loader like\n# https://github.com/bazelbuild/rules_jvm_external. See docs/scala_toolchain.md.\nscala_config()\n\nload(\n    \"@rules_scala//scala:toolchains.bzl\",\n    \"scala_register_toolchains\",\n    \"scala_toolchains\",\n)\n\n# Defines a default toolchain repo for the configured Scala version that loads\n# Maven deps like the Scala compiler and standard libs. Enable other builtin\n# toolchains by setting their corresponding parameters to `True`. See the\n# `scala_toolchains()` docstring for all builtin toolchain configuration\n# options.\n#\n# On production projects, you may consider defining a custom toolchain to use\n# your project's required dependencies instead. In that case, you can omit\n# `scala_toolchains()` or explicitly set `scala = False` if you use it to\n# instantiate other builtin toolchains.\nscala_toolchains()\n\nscala_register_toolchains()\n```\n\n### Important changes in `rules_scala` v7.0.0 configuration\n\nThe above configuration snippet reflects important changes since `rules_scala`\nv6.x:\n\n- __`rules_scala` no longer requires the `io_bazel_rules_scala` repository\n    name__ unless your `BUILD` files or those of your dependencies require it\n    (bazelbuild/rules_scala#1696).\n\n    Update your project's `@io_bazel_rules_scala` references to `@rules_scala`\n    if possible. Otherwise, use `repo_name = \"io_bazel_rules_scala\"` in\n    `bazel_dep()` or `name = \"io_bazel_rules_scala\"` in `http_archive`.\n\n    You can use the `repo_mapping` attribute of `http_archive` or equivalent\n    Bzlmod mechanisms to translate `@rules_scala` to `@io_bazel_rules_scala` for\n    dependencies. See the [Translating repo names for\n    dependencies](#repo-mapping) section below for details. (That section is\n    about `@rules_scala_config`, but the same mechanisms apply.)\n\n- __`rules_scala` v7.0.0 introduces a new `scala_toolchains()` API that is\n    very different from `rules_scala` 6__. For details on what's changed, see\n    the [New 'scala_toolchains()' API for 'WORKSPACE'](#new-toolchains-api)\n    section below.\n\n### Loading the `scala_*` rules\n\nAdd the following to your `BUILD` files to make the `scala_*` rules available:\n\n```py\nload(\n    \"@rules_scala//scala:scala.bzl\",\n    \"scala_binary\",\n    \"scala_library\",\n    \"scala_test\",\n)\n```\n\n### \u003ca id=\"protoc\"\u003e\u003c/a\u003eUsing a precompiled protocol compiler\n\n`rules_scala` now supports the\n[`--incompatible_enable_proto_toolchain_resolution`][] flag when using\n[protobuf v29 or later](#why-proto-v29). When using this flag with the\n`MODULE.bazel` or `WORKSPACE` configurations below, `rules_scala` will use a\nprecompiled protocol compiler binary by default.\n\n[`--incompatible_enable_proto_toolchain_resolution`]: https://bazel.build/reference/command-line-reference#flag--incompatible_enable_proto_toolchain_resolution\n\n__Windows builds now require using `protobuf` v29 or later with the precompiled\nprotocol compiler toolchain.__ See the [Windows MSVC builds of protobuf broken\nby default](#protoc-msvc) section below for details.\n\n#### Common setup\n\nTo set the flag in your `.bazelrc` file:\n\n```txt\ncommon --incompatible_enable_proto_toolchain_resolution\n```\n\nIn both `MODULE.bazel` and `WORKSPACE`, you must register the protocol compiler\ntoolchains _before_ any other toolchains. It's safe to use even when\n`--incompatible_enable_proto_toolchain_resolution` is `False`.\n\nIt is OK to call `register_toolchains` before using the `scala_protoc` extension\nunder Bzlmod, and before the `scala_protoc_toolchains()` repo rule under\n`WORKSPACE`.\n\n```py\n# MODULE.bazel\nregister_toolchains(\n    \"@rules_scala_protoc_toolchains//...:all\",\n    dev_dependency = True,\n)\n\n# WORKSPACE\nregister_toolchains(\"@rules_scala_protoc_toolchains//...:all\")\n```\n\n#### Using the `scala_protoc` module extension under Bzlmod\n\nThe `scala_protoc` module extension instantiates the protocol compiler\ntoolchain under Bzlmod. It _must_ be marked as a `dev_dependency`.\n\n```py\n# MODULE.bazel\n\nscala_protoc = use_extension(\n    \"@rules_scala//scala/extensions:protoc.bzl\",\n    \"scala_protoc\",\n    dev_dependency = True,\n)\nuse_repo(scala_protoc, \"rules_scala_protoc_toolchains\")\n```\n\n#### Invoking the `scala_protoc_toolchains()` repo rule under `WORKSPACE`\n\nThe `scala_protoc_toolchains` repo rule instantiates the protocol compiler\ntoolchain. The repo name can be anything, but we recommend\n`rules_scala_protoc_toolchains`.\n\n```py\n# WORKSPACE\n\n# Include this after loading `platforms`, `com_google_protobuf`, and\n# `rules_proto`.\nload(\"@rules_scala//protoc:toolchains.bzl\", \"scala_protoc_toolchains\")\n\nscala_protoc_toolchains(name = \"rules_scala_protoc_toolchains\")\n```\n\n#### Specifying additional `protoc` platforms\n\nUse the `platforms` parameter to specify additional [platforms][] if the\nexecution platform may differ from the host platform, as when building with\nremote execution. Valid values come from the file name suffixes of\n[protocolbuffers/protobuf releases][]. It's also safe to explicitly include the\nhost platform.\n\n[platforms]: https://bazel.build/extending/platforms\n[protocolbuffers/protobuf releases]: https://github.com/protocolbuffers/protobuf/releases\n\nFor example, imagine the host platform is macOS running on Apple Silicon, but\nthe remote execution platform is Linux running on an x86 processor.\n`rules_scala` configures the `\"osx-aarch_64\"` platform automatically. Then in\n`MODULE.bazel` you would include:\n\n```py\n# MODULE.bazel\n\nscala_protoc_toolchains(\n    name = \"rules_scala_protoc_toolchains\",\n    platforms = [\"linux-x86_64\"],\n    dev_dependency = True,\n)\n```\n\nIn `WORKSPACE` you would include:\n\n```py\n# WORKSPACE\n\nscala_protoc_toolchains(\n    name = \"rules_scala_protoc_toolchains\",\n    platforms = [\"linux-x86_64\"],\n)\n```\n\n#### Temporary required `protobuf` patch\n\nAt the moment, enabling protocol compiler toolchainization requires applying\n[protoc/0001-protobuf-19679-rm-protoc-dep.patch][]. It is the `git diff` output\nfrom the branch used to create protocolbuffers/protobuf#19679. Without it, a\ntransitive dependency on `@com_google_protobuf//:protoc` remains, causing\n`protoc` to recompile even with the precompiled toolchain registered first.\n\n[protoc/0001-protobuf-19679-rm-protoc-dep.patch]: ./protoc/0001-protobuf-19679-rm-protoc-dep.patch\n\nIf and when `protobuf` merges that pull request, or applies an equivalent fix,\nthis patch will no longer be necessary.\n\n#### `protobuf` patch setup under Bzlmod\n\nApplying the `protobuf` patch requires using [`single_version_override`][],\nwhich also requires that the patch be a regular file in your own repo. In other\nwords, neither `@rules_scala//protoc:0001-protobuf-19679-rm-protoc-dep.patch`\nnor an [`alias`][] to it will work.\n\n[`single_version_override`]: https://bazel.build/rules/lib/globals/module#single_version_override\n[`alias`]: https://bazel.build/reference/be/general#alias\n\nAssuming you've copied the patch to a file called `protobuf.patch` in the root\npackage of your repository, add the following to your `MODULE.bazel`:\n\n```py\n# MODULE.bazel\n\n# Required for protocol compiler toolchainization until resolution of\n# protocolbuffers/protobuf#19679.\nbazel_dep(\n    name = \"protobuf\",\n    version = \"30.1\",\n    repo_name = \"com_google_protobuf\",\n)\nsingle_version_override(\n    module_name = \"protobuf\",\n    patch_strip = 1,\n    patches = [\"//:protobuf.patch\"],\n    version = \"30.1\",\n)\n```\n\n#### `protobuf` patch setup under `WORKSPACE`\n\n[`scala/deps.bzl`](./scala/deps.bzl) currently applies the `protobuf` patch to `protobuf` v30.1.\n\nIf you need to apply the patch to a different version of `protobuf`, copy it to\nyour repo as described in the Bzlmod setup above. Then apply it in your own\n`http_archive` call:\n\n```py\nhttp_archive(\n    name = \"com_google_protobuf\",\n    sha256 = \"1451b03faec83aed17cdc71671d1bbdfd72e54086b827f5f6fd02bf7a4041b68\",\n    strip_prefix = \"protobuf-30.1\",\n    url = \"https://github.com/protocolbuffers/protobuf/archive/refs/tags/v30.1.tar.gz\",\n    repo_mapping = {\"@com_google_absl\": \"@abseil-cpp\"},\n    patches = [\"//protobuf.patch\"],\n    patch_args = [\"-p1\"],\n)\n```\n\n#### Setting up the `@host_platform` repo under `WORKSPACE`\n\n`WORKSPACE` must include the `host_platform_repo` snippet from\n[Getting started](#getting-started) to work around bazelbuild/bazel#22558:\n\n```py\n# WORKSPACE\nload(\"@platforms//host:extension.bzl\", \"host_platform_repo\")\n\n# Instantiates the `@host_platform` repo to work around:\n# - https://github.com/bazelbuild/bazel/issues/22558\nhost_platform_repo(name = \"host_platform\")\n```\n\n#### \u003ca id=\"why-proto-v29\"\u003e\u003c/a\u003eWhy this requires `protobuf` v29 or later\n\nUsing `--incompatible_enable_proto_toolchain_resolution` with versions of\n`protobuf` before v29 causes build failures due to a missing internal Bazel\ndependency.\n\nBazel's builtin `bazel_java_proto_aspect` transitively depends on a toolchain\nwith a [`toolchain_type`][] of `@rules_java//java/proto:toolchain_type`.\nExperimentation with `protobuf` v28.2 using both Bazel 6.5.0 and 7.5.0 led to\nthe following error:\n\n```txt\nERROR: .../external/bazel_tools/src/main/protobuf/BUILD:28:15:\n  in @@_builtins//:common/java/proto/java_proto_library.bzl%bazel_java_proto_aspect\n  aspect on proto_library rule\n  @@bazel_tools//src/main/protobuf:worker_protocol_proto:\n\nTraceback (most recent call last):\n  File \"/virtual_builtins_bzl/common/java/proto/java_proto_library.bzl\",\n    line 53, column 53, in _bazel_java_proto_aspect_impl\n  File \"/virtual_builtins_bzl/common/proto/proto_common.bzl\",\n    line 364, column 17, in _find_toolchain\nError in fail: No toolchains registered for\n  '@rules_java//java/proto:toolchain_type'.\n\nERROR: Analysis of target\n  '@@bazel_tools//src/main/protobuf:worker_protocol_proto' failed\n```\n\nSee bazelbuild/rules_scala#1710 for details of the experiment.\n\nFor `protobuf` v29.0, protocolbuffers/protobuf#18308 added the\n[`@protobuf//bazel/private/toolchains`][proto-private-tc] package and updated\n`protobuf_deps()` from `@protobuf//:protobuf_deps.bzl` to register it:\n\n```py\nnative.register_toolchains(\"//bazel/private/toolchains:all\")\n```\n\n[`toolchain_type`]: https://bazel.build/extending/toolchains#writing-rules-toolchains\n[proto-private-tc]: https://github.com/protocolbuffers/protobuf/blob/v29.0/bazel/private/toolchains/BUILD.bazel\n\nprotocolbuffers/protobuf#18435 then introduced\n[`java_source_toolchain_bazel7`][java-proto-tc] with the required\n`toolchain_type`.\n\n[java-proto-tc]: https://github.com/protocolbuffers/protobuf/blob/v29.0/bazel/private/toolchains/BUILD.bazel#L50-L74\n\n#### More background on protocol compiler toolchainization\n\n- [Proto Toolchainisation Design Doc](\n    https://docs.google.com/document/d/1CE6wJHNfKbUPBr7-mmk_0Yo3a4TaqcTPE0OWNuQkhPs/edit)\n\n- [bazelbuild/bazel#7095: Protobuf repo recompilation sensitivity](\n    https://github.com/bazelbuild/bazel/issues/7095)\n\n- [bazelbuild/rules_proto#179: Implement proto toolchainisation](\n    https://github.com/bazelbuild/rules_proto/issues/179)\n\n- [rules_proto 6.0.0 release notes mentioning Protobuf Toolchainization](\n    https://github.com/bazelbuild/rules_proto/releases/tag/6.0.0)\n\n### Persistent workers\n\nTo run with a persistent worker (much faster), add the following to\nyour `.bazelrc` file:\n\n```txt\nbuild --strategy=Scalac=worker\nbuild --worker_sandboxing\n```\n\n## Coverage support\n\nTo produce a combined coverage report:\n\n```txt\nbazel coverage \\\n  --combined_report=lcov \\\n  --coverage_report_generator=\"@bazel_tools//tools/test/CoverageOutputGenerator/java/com/google/devtools/coverageoutputgenerator:Main\" \\\n  //...\n```\n\nThis should produce a single `bazel-out/_coverage/_coverage_report.dat` from all coverage files that are generated.\n\nYou can extract information from your coverage reports with\n[`lcov`](https://github.com/linux-test-project/lcov):\n\n```txt\n# For a summary:\nlcov --summary your-coverage-report.dat\n\n# For details:\nlcov --list your-coverage-report.dat\n```\n\nIf you prefer an HTML report, then you can use `genhtml` provided also by the `lcov` package.\n\nCoverage support has been only tested with [ScalaTest](http://www.scalatest.org/).\n\nPlease check [coverage.md](docs/coverage.md) for more details on coverage support.\n\n## Selecting the Scala version\n\n### With builtin toolchains\n\n`rules_scala` supports the last two released minor versions for each of Scala 2.11, 2.12, 2.13.\nPrevious minor versions may work but are supported only on a best effort basis.\n\nThe [Getting started](#getting-started) section illustrates how to select the\ndefault Scala version and configure its dependencies.\n\n### With custom toolchains\n\nYou can define your own custom [scala_toolchain](docs/scala_toolchain.md) by\ncalling `setup_scala_toolchain()` with dependencies that you specify.\n\nNote: Toolchains are a more flexible way to configure dependencies, so you should prefer that way.\nPlease also note, that the `overriden_artifacts` parameter is likely to be removed in the future.\n\n### Multiple versions (cross-compilation)\n\n`rules_scala` supports configuring multiple Scala versions and offers target-level control of which one to use.\n\nPlease check [cross-compilation.md](docs/cross-compilation.md) for more details on cross-compilation support.\n\n## Compatible Bazel versions\n\nBazel compatibility is tied directly to the versions of `protobuf` required by\nBazel and `rules_java`, and their compatibility with [scalapb/ScalaPB](\nhttps://github.com/scalapb/ScalaPB) Maven artifacts. For extensive analysis,\nsee bazelbuild/rules_scala#1647.\n\nThe Bazel versions and dependency versions in the table below represent the\nmaximum available at the time of writing.\n\n- For the actual versions used by `rules_scala`, see\n    [scala/deps.bzl](scala/deps.bzl).\n\n- See [.bazelci/presubmit.yml](./.bazelci/presubmit.yml) for the exact Bazel\n    versions verified by the continuous integration builds.\n\n| Bazel/Dependency |  `rules_scala` 7.x |\n| :-: |  :-: |\n| Bazel versions using Bzlmod\u003cbr/\u003e(Coming soon! See bazelbuild/rules_scala#1482.) | 7.6.0, 8.x,\u003cbr/\u003e`rolling`, `last_green` |\n| Bazel versions using `WORKSPACE` | 6.5.0, 7.6.0, 8.x\u003cbr/\u003e(see the [notes on 6.5.0 compatibility](#6.5.0)) |\n| `protobuf` |  v30.1 |\n| `rules_proto` | 7.1.0 |\n| `abseil-cpp` | 20250127.1 |\n| `rules_java` | 8.11.0 |\n| `ScalaPB` | 1.0.0-alpha.1 |\n\nThe next major release will likely drop support for `protobuf` versions before\nv29 and remove `rules_proto` completely. This is to comply with the guidance in\n[Protobuf News: News Announcements for Version 29.x](\nhttps://protobuf.dev/news/v29/). For more details, see this [comment from #1710\nexplaining why rules_proto remains for now](\nhttps://github.com/bazelbuild/rules_scala/pull/1710#issuecomment-2750001012).\n\n### Using a prebuilt `@com_google_protobuf//:protoc` or C++ compiler flags\n\nNewer versions of `abseil-cpp`, required by newer versions of\n`@com_google_protobuf//:protoc`, fail to compile under Bazel 6.5.0 and 7.6.0 by\ndefault. [protoc will also fail to build on Windows when using\nMSVC](#protoc-msvc). You will have to choose one of the following approaches to\nresolve this problem.\n\nYou may use protocol compiler toolchainization with `protobuf` v29 or later to\navoid recompiling `protoc`. You may want to enable this even if your build\ndoesn't break, as it saves time by avoiding frequent `protoc` recompilation. See\nthe [Using a precompiled protocol compiler](#protoc) section for details.\n\nOtherwise, if migrating to Bazel 8 isn't an immediate option, you will need to\nset the following compiler flags in `.bazelrc` per bazelbuild/rules_scala#1647:\n\n```txt\ncommon --enable_platform_specific_config\n\ncommon:linux --cxxopt=-std=c++17\ncommon:linux --host_cxxopt=-std=c++17\ncommon:macos --cxxopt=-std=c++17\ncommon:macos --host_cxxopt=-std=c++17\ncommon:windows --cxxopt=/std=c++17\ncommon:windows --host_cxxopt=/std=c++17\n```\n\nNote that this example uses `common:` config settings instead of `build:`. This\nseems to prevent invalidating the action cache between `bazel` runs, which\nimproves performance.\n\n## Usage with [bazel-deps](https://github.com/johnynek/bazel-deps)\n\nBazel-deps allows you to generate bazel dependencies transitively for maven artifacts. Generally we don't want bazel-deps to fetch\nscala artifacts from maven but instead use the ones we get from calling `scala_repositories`. The artifacts can be overridden in the\ndependencies file used by bazel-deps:\n\n```yaml\nreplacements:\n  org.scala-lang:\n    scala-library:\n      lang: scala/unmangled\n      target: \"@io_bazel_rules_scala_scala_library//:io_bazel_rules_scala_scala_library\"\n    scala-reflect:\n      lang: scala/unmangled\n      target: \"@io_bazel_rules_scala_scala_reflect//:io_bazel_rules_scala_scala_reflect\"\n    scala-compiler:\n      lang: scala/unmangled\n      target: \"@io_bazel_rules_scala_scala_compiler//:io_bazel_rules_scala_scala_compiler\"\n\n  org.scala-lang.modules:\n    scala-parser-combinators:\n      lang: scala\n      target:\n        \"@io_bazel_rules_scala_scala_parser_combinators//:io_bazel_rules_scala_scala_parser_combinators\"\n    scala-xml:\n      lang: scala\n      target:\n        \"@io_bazel_rules_scala_scala_xml//:io_bazel_rules_scala_scala_xml\"\n```\n\n## Publishing to Maven repository\n\nSee [Publish your Scala Libraries to a Maven Repository](\ndocs/publish_to_maven.md).\n\n## Dependency Tracking\n\n`rules_scala` supports multiple dependency modes including strict and unused dependency tracking. See\n[Dependency Tracking](docs/dependency-tracking.md) for more info.\n\n## Advanced configurable rules\n\nTo make the ruleset more flexible and configurable, we introduce a phase architecture. By using a phase architecture, where rule implementations are defined as a list of phases that are executed sequentially, functionality can easily be added (or modified) by adding (or swapping) phases.\n\nPhases provide 3 major benefits:\n\n- Consumers are able to configure the rules to their specific use cases by\n    defining new phases within their workspace without impacting other consumers.\n- Contributors are able to implement new functionalities by creating additional\n    default phases.\n- Phases give us more clear idea what steps are shared across rules.\n\nSee [Customizable Phase](docs/customizable_phase.md) for more info.\n\n### Phase extensions\n\n- [Scala Format](docs/phase_scalafmt.md)\n\n## Building from source\n\nBuild main sources only:\n\n```txt\nbazel build //src/...\n```\n\nRun all smaller tests:\n\n```txt\nbazel test //test/...\n```\n\nTo run the full test suite:\n\n```txt\nbash test_all.sh\n```\n\nNote: __`bazel test //...` will not work__ since we have a sub-folder on the\nroot folder which is meant to be used in a failure scenario in the integration\ntests. Similarly, to only build you should use `bazel build //src/...` due to\nthat folder.\n\n## Breaking changes in `rules_scala` 7.x\n\n__The main objective of `rules_scala` 7.x is to enable existing users to migrate\nto Bazel 8 and Bzlmod.__ To facilitate a gradual migration, it is compatible\nwith both Bazel 7 and Bazel 8, and both `WORKSPACE` and Bzlmod. It remains\ncompatible with Bazel 6.5.0 builds using `WORKSPACE` for the time being, but\nBazel 6 is no longer officially supported.\n\n`rules_java` 7.x contains the following breaking changes when upgrading from\n`rules_scala` 6.x.\n\n### \u003ca id=\"new-toolchains-api\"\u003e\u003c/a\u003eNew `scala_toolchains()` API for `WORKSPACE`\n\n`rules_scala` 7.0.0 replaces existing `*_repositories()` and `*_toolchains()`\nmacros with the combination of `rules_scala_dependencies()`,\n`scala_toolchains()`, and `scala_register_toolchains()`.\n\nThese macros no longer exist:\n\n- `jmh_repositories()`\n- `junit_repositories()`\n- `junit_toolchain()`\n- `rules_scala_setup()`\n- `rules_scala_toolchain_deps_repositories()`\n- `scala_proto_default_repositories()`\n- `scala_proto_register_enable_all_options_toolchain()`\n- `scala_proto_register_toolchains()`\n- `scala_proto_repositories()`\n- `scala_register_unused_deps_toolchains()`\n- `scala_repositories()`\n- `scalafmt_default_config()`\n- `scalafmt_repositories()`\n- `scalatest_repositories()`\n- `scalatest_toolchain()`\n- `specs2_junit_repositories()`\n- `specs2_repositories()`\n- `specs2_version()`\n- `twitter_scrooge()`\n\nReplace toolchain configurations like the following:\n\n```py\nload(\n    \"@rules_scala//scala:scala.bzl\",\n    \"rules_scala_setup\",\n    \"rules_scala_toolchain_deps_repositories\",\n)\n\nrules_scala_setup()\n\nrules_scala_toolchain_deps_repositories(fetch_sources = True)\n\n# Other dependency declarations...\n\nload(\"@rules_scala//:scala_config.bzl\", \"scala_config\")\n\nscala_config(scala_version = \"2.13.16\")\n\nload(\n    \"//testing:scalatest.bzl\",\n    \"scalatest_repositories\",\n    \"scalatest_toolchain\",\n)\n\nscalatest_repositories()\n\nscalatest_toolchain()\n\nload(\n    \"//scala/scalafmt:scalafmt_repositories.bzl\",\n    \"scalafmt_default_config\",\n    \"scalafmt_repositories\",\n)\n\nscalafmt_default_config()\n\nscalafmt_repositories()\n```\n\nwith calls to `rules_scala_dependencies()`, `scala_toolchains()` (with the\nappropriate parameters set), and `scala_register_toolchains()`:\n\n```py\nload(\"@rules_scala//scala:deps.bzl\", \"rules_scala_dependencies\")\n\nrules_scala_dependencies()\n\n# See the `WORKSPACE` configuration snippet from the \"Getting started\" section\n# above for other dependency declarations.\n\nload(\"@rules_scala//:scala_config.bzl\", \"scala_config\")\n\nscala_config(scala_version = \"2.13.16\")\n\nload(\n    \"@rules_scala//scala:toolchains.bzl\",\n    \"scala_register_toolchains\",\n    \"scala_toolchains\",\n)\n\nscala_toolchains(\n    scalafmt = True,\n    scalatest = True,\n)\n\nscala_register_toolchains()\n```\n\nSee the [`scala_toolchains()`](./scala/toolchains.bzl) docstring for the\nparameter list, which is almost in complete correspondence with parameters from\nthe previous macros. The `WORKSPACE` files in this repository also provide many\nexamples.\n\n### Replacing toolchain registration macros in `WORKSPACE`\n\nAlmost all `rules_scala` toolchains configured using `scala_toolchains()` are\nautomatically registered by `scala_register_toolchains()`. There are two\ntoolchain macro replacements that require special handling.\n\nThe first is replacing `scala_proto_register_enable_all_options_toolchain()`\nwith the following `scala_toolchains()` parameters:\n\n```py\nscala_toolchains(\n    scala_proto = True,\n    scala_proto_options = [],\n)\n```\n\nThe other is replacing `scala_register_unused_deps_toolchains()` with an\nexplicit `register_toolchains()` call:\n\n```py\nregister_toolchains(\n    \"@rules_scala//scala:unused_dependency_checker_error_toolchain\",\n)\n```\n\nIn `WORKSPACE`, this `register_toolchains()` call must come before calling\n`scala_register_toolchains()` to ensure this toolchain takes precedence. The\nsame exact call will also work in `MODULE.bazel`.\n\n### Disabling builtin Scala toolchains when defining custom Scala toolchains\n\nWhen [using 'setup_scala_toolchain()' with custom compiler JARs](\ndocs/scala_toolchain.md#b-defining-your-own-scala_toolchain), don't use\n`scala_toolchains()` if you don't need any other builtin toolchains.\n\nIf you do need other builtin toolchains, then set `scala = False`:\n\n```py\n# WORKSPACE\nscala_toolchains(\n    scala = False,\n    # ...other toolchain parameters...\n)\n```\n\nThis avoids instantiating the default Scala toolchain and compiler JAR\nrepositories, and disables the corresponding Scala version check, which may\notherwise fail. This is equivalent to two ways in which the previous API avoided\nthe same default behavior:\n\n- Calling `scala_repositories(load_jar_deps = False)` would instantiate only\n    other `rules_scala` dependency repos (`rules_java`, `protobuf`, etc.) and\n    compiler source JAR repos.\n\n- Calling `rules_scala_setup()` directly, instead of indirectly via\n    `scala_repositories()`, instantiated the other dependency repositories only.\n\nSee [\"Defining your own scala_toolchain \u003e Step 3 (optional)\" from\ndocs/scala_toolchain.md](docs/scala_toolchain.md#step-3-optional) for futher\ndetails.\n\n### Bzlmod configuration (coming soon!)\n\nThe upcoming Bzlmod implementation will funnel through the `scala_toolchains()`\nmacro as well, ensuring maximum compatibility with `WORKSPACE` configurations.\nThe equivalent Bzlmod configuration for the `scala_toolchains()` configuration\nabove would be:\n\n```py\nbazel_dep(name = \"rules_scala\", version = \"7.0.0\")\n\nscala_config = use_extension(\n    \"@rules_scala//scala/extensions:config.bzl\",\n    \"scala_config\",\n)\nscala_config.settings(scala_version = \"2.13.16\")\n\nscala_deps = use_extension(\n    \"@rules_scala//scala/extensions:deps.bzl\",\n    \"scala_deps\",\n)\nscala_deps.toolchains(\n    scalafmt = True,\n    scalatest = True,\n)\n```\n\nThe module extensions will call `scala_config()` and `scala_toolchains()`\nrespectively. The `MODULE.bazel` file for `rules_scala` declares its own\ndependencies via `bazel_dep()`, allowing Bazel to resolve versions according to\nthe main repository/root module configuration. It also calls\n[`register_toolchains()`][reg_tool], so you don't have to (unless you want to\nregister a specific toolchain to resolve first).\n\n[reg_tool]: https://bazel.build/rules/lib/globals/module#register_toolchains\n\nThe `MODULE.bazel` files in this repository will also provide many examples\n(when they land per bazelbuild/rules_scala#1482).\n\n#### Copy `register_toolchains()` calls from `WORKSPACE` to `MODULE.bazel`\n\nThe `MODULE.bazel` file from `rules_scala` will automatically call\n`register_toolchains()` for toolchains configured via its `scala_deps` module\nextension. However, you must register explicitly in your `MODULE.bazel` file any\ntoolchains that you want to take precedence over the toolchains configured by\n`scala_deps`. This includes any [`scala_toolchain`](./docs/scala_toolchain.md)\ntargets defined in your project, or optional `rules_scala` toolchains like the\ndependency checker error toolchain from above:\n\n```py\nregister_toolchains(\n    \"@rules_scala//scala:unused_dependency_checker_error_toolchain\",\n)\n```\n\n### `@io_bazel_rules_scala_config` is now `@rules_scala_config`\n\nSince `@io_bazel_rules_scala` is no longer hardcoded in `rules_scala` internals,\nwe've shortened `@io_bazel_rules_scala_config` to `@rules_scala_config`. This\nshouldn't affect most users, but it may break some builds using\n`@io_bazel_rules_scala_config` to define custom [cross-compilation targets](\n./docs/cross-compilation.md).\n\nIf your project uses Bzlmod, you can remap `@io_bazel_rules_scala_config` to\n`@rules_scala_config` for your own project via [`use_repo()`]. Use this only if\nupdating your project's own `@io_bazel_rules_scala_config` references isn't\nimmediately feasible.\n\n[`use_repo()`]: https://bazel.build/rules/lib/globals/module#use_repo\n\n```py\nscala_config = use_extension(\n    \"@rules_scala//scala/extensions:config.bzl\",\n    \"scala_config\",\n)\nuse_repo(scala_config, io_bazel_rules_scala_config = \"rules_scala_config\")\n```\n\nIf your project uses `WORKSPACE` you _must_ update all\n`@io_bazel_rules_scala_config` references to `@rules_scala_config`. There is no\n`use_repo()` equivalent.\n\n#### \u003ca id=\"repo-mapping\"\u003e\u003c/a\u003eTranslating repo names for dependencies\n\nFor any dependencies referencing `@io_bazel_rules_scala_config`, use the workarounds\nbelow. The same workarounds for your project's dependencies also apply to\ntranslating `@rules_scala` to `@io_bazel_rules_scala`.\n\n#### Bzlmod\n\nFor module extensions, use [`override_repo()`][] to override\n`@io_bazel_rules_scala_config` with `@rules_scala_config`:\n\n```py\nbazel_dep(name = \"foo\", version = \"1.0.0\")\n\nfoo_ext = use_extension(\"@foo//:ext.bzl\", \"foo_ext\")\noverride_repo(foo_ext, io_bazel_rules_scala_config = \"rules_scala_config\")\n```\n\n[`bazel_dep()`][] dependencies may still require `@io_bazel_rules_scala_config`\n(or `@io_bazel_rules_scala`) outside of a module extension. In this case, to\navoid using the old name in your own project, use [`archive_override()`][] or\n[`git_override()`][] with the `repo_mapping` attribute. These overrides pass the\n`repo_mapping` through to the underlying [`http_archive()`][] and\n[`git_repository()`][] rules:\n\n```py\narchive_override(\n    ...\n    repo_mapping = {\n        \"@io_bazel_rules_scala_config\": \"@rules_scala_config\",\n    }\n    ...\n)\n```\n\n[`override_repo()`]: https://bazel.build/rules/lib/globals/module#override_repo\n[`bazel_dep()`]: https://bazel.build/rules/lib/globals/module#bazel_dep\n[`archive_override()`]: https://bazel.build/rules/lib/globals/module#archive_override\n[`git_override()`]: https://bazel.build/rules/lib/globals/module#git_override\n[`http_archive()`]: https://bazel.build/rules/lib/repo/http#http_archive-repo_mapping\n[`git_repository()`]: https://bazel.build/rules/lib/repo/git#git_repository-repo_mapping\n\n#### `WORKSPACE`\n\nFor dependencies, use the `repo_mapping` attribute of [`http_archive()`][] or\n[`git_repository()`][]:\n\n```py\nhttp_archive(\n    ...\n    repo_mapping = {\n        \"@io_bazel_rules_scala_config\": \"@rules_scala_config\",\n    }\n    ...\n)\n```\n\n### \u003ca id=\"protoc-msvc\"\u003e\u003c/a\u003eWindows MSVC builds of `protobuf` broken by default\n\nMSVC builds of recent `protobuf` versions started failing, as first noted in\nbazelbuild/rules_scala#1710. On top of that, `protobuf` is planning to stop\nsupporting Bazel + MSVC builds per:\n\n- [protocolbuffers/protobuf#12947: src build on windows not working](\n    https://github.com/protocolbuffers/protobuf/issues/12947)\n\n- [protobuf.dev News Announcements for Version 30.x:Poison MSVC + Bazel](\n    https://protobuf.dev/news/v30/#poison-msvc--bazel)\n\n- [protocolbuffers/protobuf#20085: Breaking Change: Dropping support for\n    Bazel+MSVC](https://github.com/protocolbuffers/protobuf/issues/20085)\n\nEnable [protocol compiler toolchainization](#protoc) to fix broken Windows\nbuilds by avoiding `@com_google_protobuf//:protoc` recompilation.\n\n### Minimum of `protobuf` v28\n\n`rules_scala` requires at least `protobuf` v28, and at least v29 for [protocol\ncompiler toolchain](#protoc) support. No `ScalaPB` release supports `protobuf`\nv25.6, v26, or v27.\n\n#### Using earlier `protobuf` versions\n\nIf you can't update to `protobuf` v28 or later right now, build using Bazel 7\nand the following maximum versions of key dependencies. This is not officially\nsupported, but should work for some time.\n\n| Dependency | Max compatible version | Reason |\n| :-: | :-: | :- |\n| `protobuf` | v25.5 | Maximum version supported by `ScalaPB` 0.11.17. |\n| `rules_proto` | 6.0.2 | Maximum version supporting `protobuf` v25.5 |\n| `rules_java` | 7.12.4 | 8.x requires `protobuf` v27 and later. |\n| `rules_cc` | 0.0.9 | 0.0.10 requires Bazel 7 to define `CcSharedLibraryHintInfo`.\u003cbr/\u003e0.0.13 requires at least `protobuf` v27.0. |\n| `ScalaPB` | 0.11.17\u003cbr/\u003e(0.9.8 for Scala 2.11) | Later versions only support `protobuf` \u003e= v28. |\n\n### Embedded resource paths no longer begin with `external/\u003crepo_name\u003e`\n\n[Any program compiled with an external repo asset in its 'resources' attribute\nwill need to strip the 'external/' and repo name components from its\npath][ext-path]. For example, the path for `resources =\n[\"@some_external_repo//:resource.txt\"]` would change thus:\n\n[ext-path]: https://github.com/bazelbuild/rules_scala/pull/1621#issuecomment-2417506589\n\n- Before: `external/some_external_repo/resource.txt`\n- After: `resource.txt`\n\nThis avoids encoding repo names or any other Bazel system knowledge in the\ncompiled artifacts. This is especially important under Bzlmod, because the\ngenerated path would otherwise contain [the _canonical_ repo name,  upon which\nusers should never\ndepend](https://bazel.build/external/module#repository_names_and_strict_deps).\n\n### Update `@bazel_tools//tools/jdk` targets to `@rules_java//toolchains` targets\n\nPer bazelbuild/rules_scala#1660, `rules_java` 7.10.0 and later precipitate the\nneed to replace `@bazel_tools//tools/jdk` targets with corresponding\n`@rules_java//toolchains` targets. Fix any targets broken by this `rules_java`\nupgrade by doing a global search and replace.\n\nHowever, `@bazel_tools//tools/jdk:toolchain_type` dependencies must remain for\nnow, as there's not yet a corresponding [`toolchain_type()`](\nhttps://bazel.build/versions/6.1.0/reference/be/platform#toolchain_type) target\nin `@rules_java`.\n\n### Builtin repositories no longer visible by default under Bzlmod\n\nUnder Bzlmod, repos are only visible to the module extension that creates them,\nunless the `MODULE.bazel` file brings them into scope with\n[`use_repo()`](https://bazel.build/rules/lib/globals/module#use_repo). This can\nlead to errors like those from the following example, which [originally called\n'setup_scala_toolchain()' under Bzlmod](\nhttps://github.com/michalbogacz/scala-bazel-monorepo/blob/17f0890a4345529e09b9ce83bcb2e3d15687c522/BUILD.bazel):\n\n```py\nload(\"@rules_scala//scala:scala.bzl\", \"setup_scala_toolchain\")\n\nsetup_scala_toolchain(\n    name = \"custom_scala_toolchain\",\n    scalacopts = [\n        \"-Wunused:all\",\n    ],\n    strict_deps_mode = \"error\",\n    unused_dependency_checker_mode = \"warn\",\n)\n```\n\n`setup_scala_toolchains` is a macro that can take user specified classpath\ntargets as described in [docs/scala_toolchain.md](./docs/scala_toolchain.md).\nWithout explicit `*_classpath` or `*_deps` arguments, `setup_scala_toolchain()`\ndefaults to using dependency repositories generated by `rules_scala` itself.\nThis worked under `WORKSPACE`, but breaks under Bzlmod, because the builtin\ntoolchain dependency repos are no longer in the project's scope by default:\n\n```txt\nERROR: no such package\n    '@@[unknown repo 'org_scala_sbt_compiler_interface_3_3_5'\n        requested from @@]//':\n    The repository '@@[unknown repo 'org_scala_sbt_compiler_interface_3_3_5'\n        requested from @@]' could not be resolved:\n    No repository visible as '@org_scala_sbt_compiler_interface_3_3_5'\n```\n\nIn this case, where the toolchain only sets different compiler options, the best\nfix is to [use the 'scala_toolchain' rule directly instead][scala_tc_direct].\nIts underlying `BUILD` rule uses builtin toolchain dependencies via existing\ntargets visible within `rules_scala`, without forcing users to import them:\n\n[scala_tc_direct]: https://github.com/michalbogacz/scala-bazel-monorepo/blob/2cac860f386dcaa1c3be56cd25a84b247d335743/BUILD.bazel\n\n```py\nload(\"@rules_scala//scala:scala_toolchain.bzl\", \"scala_toolchain\")\n\nscala_toolchain(\n    name = \"custom_scala_toolchain_impl\",\n    scalacopts = [\n        \"-Ywarn-unused\",\n    ],\n    strict_deps_mode = \"error\",\n    unused_dependency_checker_mode = \"warn\",\n)\n\ntoolchain(\n    name = \"custom_scala_toolchain\",\n    toolchain = \":custom_scala_toolchain_impl\",\n    toolchain_type = \"@rules_scala//scala:toolchain_type\",\n    visibility = [\"//visibility:public\"],\n)\n```\n\nA big part of the Bzlmodification work involved enabling `rules_scala` to\ngenerate and register toolchains _without_ forcing users to bring their\ndependencies into scope. However, another way to fix this specific problem is to\ncall `use_repo` for every builtin repository needed by the\n`setup_scala_toolchain()` call.\n\n### Replace some `$(location)` calls with `$(rootpath)` for Bazel 8\n\nThis isn't actually a `rules_scala` breakage, but a Bazel 8 breakage encountered\nwhile preparing `rules_scala` for Bazel 8 in bazelbuild/rules_scala#1652.\nbazelbuild/bazel#25198 describes how the semantics of some instances of\n`$(location)` changed, and how changing these particular instances to\n`$(rootpath)` fixed them.\n\nThe good news is that replacing such instances `$(location)` with `$(rootpath)`\nis backwards compatible to Bazel 6.5.0 and 7.6.0. Updating them now will ensure\nfuture compatibility.\n\n### \u003ca id=\"6.5.0\"\u003e\u003c/a\u003eLimited Bazel 6.5.0 compatibility\n\n__`rules_scala` 7.x officially drops support for Bazel 6.5.0.__ Bzlmod builds\nwith Bazel 6.5.0 won't work at all because [Bazel 6.5.0 doesn't support\n'use_repo_rule']( https://bazel.build/versions/6.5.0/rules/lib/globals), which\n['rules_jvm_external' \u003e= 6.3 requires](\nhttps://github.com/bazelbuild/rules_scala/issues/1482#issuecomment-2515496234).\n\nAt the moment, `WORKSPACE` builds mostly continue to work with Bazel 6.5.0, but\nnot out of the box, and may break at any time.\n\n#### Maximum of `protobuf` v29\n\nYou _must_ use `protobuf` v29 or earlier. `rules_scala` now uses v30 by default,\nwhich removes `py_proto_library` and other symbols that Bazel 6.5.0 requires:\n\n```txt\nERROR: Traceback (most recent call last):\n  File \".../external/bazel_tools/src/main/protobuf/BUILD\",\n  line 1, column 46, in \u003ctoplevel\u003e\n    load(\"@com_google_protobuf//:protobuf.bzl\", \"py_proto_library\")\n\nError: file '@com_google_protobuf//:protobuf.bzl'\n  does not contain symbol 'py_proto_library'\n\nERROR: .../src/java/io/bazel/rulesscala/worker/BUILD:3:13:\n  no such target '@bazel_tools//src/main/protobuf:worker_protocol_java_proto':\n  target 'worker_protocol_java_proto'\n  not declared in package 'src/main/protobuf'\n  defined by .../external/bazel_tools/src/main/protobuf/BUILD\n  (Tip: use `query \"@bazel_tools//src/main/protobuf:*\"`\n    to see all the targets in that package)\n  and referenced by '//src/java/io/bazel/rulesscala/worker:worker'\n```\n\n#### Configuring the protocol compiler toolchain\n\nSee [Using a prebuilt @com_google_protobuf//:protoc or C++ compiler\nflags][protoc-opts] for protocol compiler configuration requirements.\n\n[protoc-opts]: #using-a-prebuilt-com_google_protobufprotoc-or-c-compiler-flags\n\n#### Using older versions of `protobuf`\n\nSee [Using earlier protobuf versions](#using-earlier-protobuf-versions) for\ndetails on using older versions of protobuf if necessary.\n\n### `scala_proto` not supported for Scala 2.11\n\n[ScalaPB 0.9.8](https://github.com/scalapb/ScalaPB/releases/tag/v0.9.8), the\nlast version compatible with Scala 2.11, doesn't support `protobuf` v25.6 or\nlater. See bazelbuild/rules_scala#1712 for an example of what happens to Scala\n2.11 test cases when using `protobuf` v25.6. Since `rules_scala` now supports\nmore recent `protobuf` versions via [ScalaPB 1.0.0-alpha1](\nhttps://github.com/scalapb/ScalaPB/releases/tag/v1.0.0-alpha.1), we had to\nremove the Scala 2.11 test cases.\n\nBuilding `scala_proto` for Scala 2.11 requires [building with Bazel 6.5.0\nunder WORKSPACE](#6.5.0), with the maximum dependency versions specified in\nthat section. While this may continue to work for some time, it is not\nofficially supported.\n\n### `scala_proto_toolchain` changes and new `scalapb_toolchain` macro\n\n`scala_proto_toolchain` has a more flexible plugin configuration schema. The\nnew `generators` and `generators_opts` attributes replace the following\nattributes:\n\n- `with_grpc`\n- `with_flat_package`\n- `with_single_line_to_string`\n- `main_generator`\n- `named_generators`\n\nNow each generator (plugin) will get a corresponding name\nthat can be used for further plugin options setup:\n\n```py\nscala_proto_toolchain(\n    name = \"example\",\n    generators = {\n        \"scala\": \"scripts.ScalaPbCodeGenerator\",\n        \"jvm_extra_protobuf_generator\": \"scalarules.test.extra_protobuf_generator.ExtraProtobufGenerator\",\n    },\n    generators_opts = {\n        \"scala\": [\n            \"grpc\",\n            \"single_line_to_proto_string\",\n        ],\n        \"jvm_extra_protobuf_generator\": [\n            \"grpc\",\n            \"single_line_to_proto_string\",\n        ],\n    },\n)\n```\n\n`scalapb_grpc_deps` no longer exists since it's now the user's responsibility\nto configure dependencies based on the provided generators and their options.\n\nThe new `scalapb_toolchain` convenience macro wraps `scala_proto_toolchain`\nto provide the default [ScalaPB](https://scalapb.github.io/) implementation:\n\n```py\nload(\"//scala_proto:scala_proto_toolchain.bzl\", \"scalapb_toolchain\")\n\nscalapb_toolchain(\n    name = \"my_toolchain\",\n    opts = [\n        \"grpc\",\n        \"single_line_to_proto_string\",\n    ],\n    visibility = [\"//visibility:public\"],\n)\n```\n\nSimilarly, `setup_scala_proto_toolchains()` now uses a `default_gen_opts`\nparameter to replace the previous boolean `enable_all_options` parameter.\n\n### Removal of `bind()` aliases for `twitter_scrooge` dependencies\n\n`rules_scala` 7.x removes all of the obsolete [`bind()`][] aliases under\n`//external:io_bazel_rules_scala/dependency/` created for `twitter_scrooge`\ntoolchain dependencies. If your project happens to depend on these aliases, you\ncan replace them with the following repository references:\n\n| `bind()` alias under `//external:io_bazel_rules_scala/dependency/` | Repository reference |\n| :-- | :-- |\n| `scala/guava` | `@io_bazel_rules_scala_guava` |\n| `thrift/javax_annotation_api` | `@io_bazel_rules_scala_javax_annotation_api` |\n| `thrift/libthrift` | `@libthrift` |\n| `thrift/mustache` | `@io_bazel_rules_scala_mustache` |\n| `thrift/scopt` | `@io_bazel_rules_scala_scopt` |\n| `thrift/scrooge_core` | `@io_bazel_rules_scala_scrooge_core` |\n| `thrift/scrooge_generator` | `@io_bazel_rules_scala_scrooge_generator` |\n| `thrift/util_core` | `@io_bazel_rules_scala_util_core` |\n| `thrift/util_logging` | `@io_bazel_rules_scala_util_logging` |\n\n[`bind()`]: https://bazel.build/reference/be/workspace#bind\n\nTo access these repositories under Bzlmod, you'll need to add the following to\nyour `MODULE.bazel` file:\n\n```py\nscala_deps.toolchains(\n    twitter_scrooge = True,\n)\nuse_repo(\n    scala_deps,\n    \"io_bazel_rules_scala_guava\",\n    \"io_bazel_rules_scala_javax_annotation_api\",\n    \"io_bazel_rules_scala_mustache\",\n    \"io_bazel_rules_scala_scopt\",\n    \"io_bazel_rules_scala_scrooge_core\",\n    \"io_bazel_rules_scala_scrooge_generator\",\n    \"io_bazel_rules_scala_util_core\",\n    \"io_bazel_rules_scala_util_logging\",\n    \"libthrift\",\n)\n```\n\n### Bazel module compatibility levels\n\n`rules_scala` 7.0.0 will set the\n[`compatibility_level`](https://bazel.build/external/module#compatibility_level)\nvalue for its [`module()`](https://bazel.build/rules/lib/globals/module)\ndirective. The `compatibility_level` for `rules_scala` will track major version\nnumbers (per [semantic versioning](https://semver.org/)), and this `README` will\nclearly document the reason for the level bump. `compatibility_level` mismatches\nin the module graph will cause module resolution to fail, signaling the presence\nof known breaking changes.\n\nThe concept of proper `compatibility_level` usage is still up for discussion in\nbazelbuild/bazel#24302. However, the policy above favors forcing module\nresolution to fail, rather than allowing a later execution step to fail with a\npotentially confusing error message. If a version bump may break builds for any\nknown reason, we will explain why up front instead of waiting for users to be\nsurprised.\n\n[A comment from #1647 illustrates how 'rules_erlang' fails due to\n'compatibility_level' conflicts][erlang]. The ['rules_erlang' 3.0.0 release\nnotes](https://github.com/rabbitmq/rules_erlang/releases/tag/3.0.0) describe the\nbreaking changes. This seems like a reasonable model to follow.\n\n[erlang]: https://github.com/bazelbuild/rules_scala/issues/1647#issuecomment-2486777859\n\n## Contributing\n\nSee [CONTRIBUTING.md](CONTRIBUTING.md) for more info.\n\n## Adopters\n\nHere's a (non-exhaustive) list of companies that use `rules_scala` in production. Don't see yours? [You can add it in a PR](https://github.com/bazelbuild/rules_scala/edit/master/README.md)!\n\n- [Ascend](https://ascend.io/)\n- [Canva](https://www.canva.com/)\n- [Domino Data Lab](https://www.dominodatalab.com/)\n- [Etsy](https://www.etsy.com/)\n- [Gemini](https://gemini.com/)\n- [Grand Rounds](http://grandrounds.com/)\n- [Kitty Hawk](https://kittyhawk.aero/)\n- [Meetup](https://meetup.com/)\n- [Spotify](https://www.spotify.com/)\n- [Stripe](https://stripe.com/)\n- [Tally](https://www.meettally.com/)\n- [Twitter](https://twitter.com/)\n- [VirtusLab](https://virtuslab.com/)\n- [VSCO](https://vsco.co)\n- [Wix](https://www.wix.com/)\n- [Yobi](https://www.yobi.ai/)\n","funding_links":[],"categories":["Additional language support"],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fbazelbuild%2Frules_scala","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fbazelbuild%2Frules_scala","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fbazelbuild%2Frules_scala/lists"}