Skip to content

fix(paywalls): Expose compose-foundation-layout so PaywallFooter is callable without extra setup #3961

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
AlvaroBrey merged 2 commits into from
Aug 13, 2026
Merged

fix(paywalls): Expose compose-foundation-layout so PaywallFooter is callable without extra setup #3961

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
191afa3
fix(paywalls): expose compose-foundation-layout as an api dependency
AlvaroBrey Aug 13, 2026
f6924a3
Remove unneeded comment
AlvaroBrey Aug 13, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions gradle/libs.versions.toml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -126,6 +126,7 @@ commonmark-strikethrough = { module = "org.commonmark:commonmark-ext-gfm-striket

compose-bom = { module = "androidx.compose:compose-bom", version.ref = "composeBom" }
compose-constraintlayout = { module = "androidx.constraintlayout:constraintlayout-compose", version.ref = "constraintlayout" }
compose-foundation-layout = { module = "androidx.compose.foundation:foundation-layout" }
compose-material = { module = "androidx.compose.material:material" }
compose-material3 = { module = "androidx.compose.material3:material3" }
compose-material3Adaptive = { module = "androidx.compose.material3.adaptive:adaptive" }
Expand Down
3 changes: 2 additions & 1 deletion ui/revenuecatui/build.gradle.kts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -88,8 +88,9 @@ tasks.withType<KotlinCompile>().configureEach {

dependencies {
api(project(":purchases"))
api(platform(libs.compose.bom))
api(libs.compose.foundation.layout)

@tonidero tonidero Aug 13, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Not related to this line]

Hmm so exposing those types in our API was a mistake 😅 This means that we are now tied to the compose API, and if they have breaking changes, we would need to do a major as well theoretically :(

In my mind the appropriate fix would be to, since we need to do a major. Change the public API of the PaywallFooter types to avoid exposing any compose types + hide (make internal) the CloseButton that seems like something we shouldn't have ever exposed. Wdyt @AlvaroBrey @JayShortway?

@AlvaroBrey AlvaroBrey Aug 13, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't we expose a bunch of Compose types in the ui module anyway? I don't think these are the only ones by far (and also it's a compose-aware UI lib, we are kinda supposed to?)

@tonidero tonidero Aug 13, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well... we do expose annotations like @Composable or @Immutable and some types like FontFamily... It's not great since it means that, if we want to update compose, and that update includes a breaking change, we could potentially be breaking someone that might be using an older version of compose, so not ideal...

But yeah, you do have a good point, and I don't have a good thought on how to workaround those annotations and types we already expose... So with that in mind, I guess I'm ok with this then. 👍

@JayShortway JayShortway Aug 13, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if we want to update compose, and that update includes a breaking change, we could potentially be breaking someone that might be using an older version of compose

I think this is true regardless of implementation/api, because we will pull in the newer compose version and that will win over the older version the app has declared (in a standard setup).

It's the most correct (tm) to declare Compose as api indeed because it is part of our public API. One question: do we need to make the bom api too, or is foundation.layout enough?

@tonidero tonidero Aug 13, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm you're right... so yeah please ignore me 😅 🙇 . Not sure if we need to also api the bom TBH... But in the PR description:

Without it the published Gradle metadata lists foundation-layout with no version in the api
variant, so a consumer without their own Compose BOM could not resolve it.

So it seems it is?

@AlvaroBrey AlvaroBrey Aug 13, 2026 •
edited
Loading

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, for the reasons above we need to either set the bom as api, or set a explicit version for foundation-layout


implementation(platform(libs.compose.bom))
implementation(libs.compose.ui)
implementation(libs.compose.ui.util)
implementation(libs.compose.ui.graphics)
Expand Down