Skip to content

feat: mark development deps as dev_dependency and make swift_deps_info unique#1982

Draft
luispadron wants to merge 1 commit into
mainfrom
luis/mark-dev-extension
Draft

feat: mark development deps as dev_dependency and make swift_deps_info unique#1982
luispadron wants to merge 1 commit into
mainfrom
luis/mark-dev-extension

Conversation

@luispadron
Copy link
Copy Markdown
Collaborator

@luispadron luispadron commented Jan 10, 2026

BREAKING CHANGES:

  • Users which require swift_deps_info to be declared must now specify a module(name) in their MODULE.bazel.
  • Development repositories like swift_package are marked as dev dependencies.
  • The name of the swift_deps_info repository will now be prefixed by the Bazel module name that defines it.

This change works towards #769, in order to support rules_swift_package_manager usage in multiple modules within a single Bazel module we must make the swift_deps_info and swift_package repositories unique.

For swift_deps_info we do this by prefixing it with the name of the defining Bazel module (via module(name = "...")). I opted for this because defining swift_deps_info as a dev dependency means we'd effectively run the SPM commands to dump the package and such multiple times. I opened bazelbuild/bazel#28210 to look into a better way to define dev dependencies without requiring multiple use_extension calls.

For swift_package we can define it as a dev_dependency as it doens't share much with the swift_deps extension. To do this we create a new swift_dev_deps extension which can be used to define dev dependencies, for now just swift_package. This extension is used with use_extension(..., dev_dependency = True). This ensures it is not part of the Bazel module resolution.

Example before:

swift_deps = use_extension(
    "@rules_swift_package_manager//:extensions.bzl",
    "swift_deps",
)
swift_deps.from_package(
    registries = "//:registries.json",
    resolved = "//:Package.resolved",
    swift = "//:Package.swift",
)
swift_deps.configure_swift_package(
    replace_scm_with_registry = True,
)
use_repo(
    swift_deps,
    "swift_package",
    "swiftpkg_apple.swift_collections",
    "swiftpkg_apple.swift_nio",
    "swiftpkg_swift_async_algorithms",
)

Example after:

swift_deps = use_extension(
    "@rules_swift_package_manager//:extensions.bzl",
    "swift_deps",
)
swift_deps.from_package(
    registries = "//:registries.json",
    replace_scm_with_registry = True,
    resolved = "//:Package.resolved",
    swift = "//:Package.swift",
)
use_repo(
    swift_deps,
    "swiftpkg_apple.swift_collections",
    "swiftpkg_apple.swift_nio",
    "swiftpkg_swift_async_algorithms",
)

swift_dev_deps = use_extension(
    "@rules_swift_package_manager//:extensions.bzl",
    "swift_dev_deps",
    dev_dependency = True,
)
swift_dev_deps.from_package(
    registries = "//:registries.json",
    replace_scm_with_registry = True,
    swift = "//:Package.swift",
)
use_repo(swift_dev_deps, "swift_package")

@luispadron luispadron changed the title feat: mark development deps as dev_dependency feat: mark development deps as dev_dependency and make swift_deps_info unique Jan 10, 2026
@luispadron luispadron force-pushed the luis/mark-dev-extension branch 4 times, most recently from a735e5c to 87411ea Compare January 10, 2026 06:40
…info` unique

BREAKING CHANGES:

 - Users which require `swift_deps_info` to be declared must now specify a `module(name)` in their `MODULE.bazel`.
 - Development repositories like `swift_package` are marked as dev dependencies.
 - The name of the `swift_deps_info` repository will now be prefixed by the Bazel module name that defines it.

This change works towards #769, in order to support `rules_swift_package_manager` usage in multiple modules within a single Bazel module we must make the `swift_deps_info` and `swift_package` repositories unique.

For `swift_deps_info` we do this by prefixing it with the name of the defining Bazel module (via `module(name = "...")`). I opted for this because defining `swift_deps_info` as a dev dependency means we'd effectively run the SPM commands to dump the package and such multiple times. I opened bazelbuild/bazel#28210 to look into a better way to define dev dependencies without requiring multiple `use_extension` calls.

For `swift_package` we can define it as a `dev_dependency` as it doens't share much with the `swift_deps` extension. To do this we create a new `swift_dev_deps` extension which can be used to define dev dependencies, for now just `swift_package`. This extension is used with `use_extension(..., dev_dependency = True)`. This ensures it is not part of the Bazel module resolution.

Example before:

```starlark
swift_deps = use_extension(
    "@rules_swift_package_manager//:extensions.bzl",
    "swift_deps",
)
swift_deps.from_package(
    registries = "//:registries.json",
    resolved = "//:Package.resolved",
    swift = "//:Package.swift",
)
swift_deps.configure_swift_package(
    replace_scm_with_registry = True,
)
use_repo(
    swift_deps,
    "swift_package",
    "swiftpkg_apple.swift_collections",
    "swiftpkg_apple.swift_nio",
    "swiftpkg_swift_async_algorithms",
)
```

Example after:

```starlark
swift_deps = use_extension(
    "@rules_swift_package_manager//:extensions.bzl",
    "swift_deps",
)
swift_deps.from_package(
    registries = "//:registries.json",
    replace_scm_with_registry = True,
    resolved = "//:Package.resolved",
    swift = "//:Package.swift",
)
use_repo(
    swift_deps,
    "swiftpkg_apple.swift_collections",
    "swiftpkg_apple.swift_nio",
    "swiftpkg_swift_async_algorithms",
)

swift_dev_deps = use_extension(
    "@rules_swift_package_manager//:extensions.bzl",
    "swift_dev_deps",
    dev_dependency = True,
)
swift_dev_deps.from_package(
    registries = "//:registries.json",
    replace_scm_with_registry = True,
    swift = "//:Package.swift",
)
use_repo(swift_dev_deps, "swift_package")
```
@luispadron luispadron force-pushed the luis/mark-dev-extension branch from 87411ea to 0876a77 Compare January 10, 2026 19:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant