# Let's defuse the Compose BOM

DevFeed: [Let's defuse the Compose BOM](<https://devfeed.tech/articles/let-s-defuse-the-compose-bom-20931.md>)

Original publisher: [Read original article](<https://jakewharton.com/defuse-the-compose-bom/>)

Published: 2025-12-03T00:00:00Z

Content type: opinion

Language: en

Sources: [Jake Wharton](<https://devfeed.tech/sources/jake-wharton.md>)

Topics: [Compose](<https://devfeed.tech/topics/compose.md>), [Gradle](<https://devfeed.tech/topics/gradle.md>), [Maven](<https://devfeed.tech/topics/maven.md>), [Library](<https://devfeed.tech/topics/library.md>)

Tags: [build](<https://devfeed.tech/tags/build.md>), [compose](<https://devfeed.tech/tags/compose.md>), [dependency](<https://devfeed.tech/tags/dependency.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [libraries](<https://devfeed.tech/tags/libraries.md>)

## AI overview

The article argues that Compose BOMs may be unnecessary for Gradle users because AndroidX libraries publish peer dependency constraints in Gradle module metadata, allowing Gradle to align artifacts within a library group automatically. It also discusses Renovate and Dependabot for automated dependency updates and Gradle version catalogs for centralized version management.

## Source excerpt

Many people rely on the Compose bill of materials (BOM) artifact to provide the complete set of Compose dependency versions. If we use Compose's foundation 1.8.0 but a transitive dependency bumps foundation-layout, there's a risk that these two versions are incompatible with each other despite otherwise being stable libraries. The Compose BOM will unify the versions so that all are guaranteed to work with each other. Since Compose comprises about 15 individual libraries, the Compose BOM provides us with only a single version that we have to manually change when upgrading. Nice and simple. But wait... We don't really need those things! Every AndroidX library automatically bundles peer dependency constraints into its Gradle module metadata which ensures that within a library group all artifacts resolve to the same version. Here's a fragment from the Gradle module metadata for foundation-layout v1.10.0: "dependencyConstraints": [ { "group": "androidx.compose.foundation", "module": "foundation", "version": { "requires": "1.10.0" }, "reason": "foundation-layout is in atomic group androidx.compose.foundation" }, { "group": "androidx.compose.foundation", "module": "foundation-lint", "version": { "requires": "1.10.0" }, "reason": "foundation-layout is in atomic group androidx.compose.foundation" } ], This means that in the scenario above, with a mismatched transitive dependency bump, the module metadata instructs Gradle to automatically bump all artifacts in that group. No manual action or BOM usage required. As to the single version, did you know there's actually only five library groups in the Compose BOM? Despite encompassing about 15 libraries, it's only actually defining four distinct versions (Compose UI and Material library groups share a version). Tools like Renovate or Dependabot can track the libraries in use and query upstream Maven repositories for new versions. When one is available, a PR is automatically created bumping the affected libraries. No manual version