Skip to content

Integrate convention plugins into Version Catalogs#3181

Merged
tonidero merged 1 commit into
RevenueCat:external/AlexanderTalledo/integrate-convention-plugins-into-version-catalogsfrom
AlexanderTalledo:integrate-convention-plugins-into-version-catalogs
Mar 9, 2026
Merged

Integrate convention plugins into Version Catalogs#3181
tonidero merged 1 commit into
RevenueCat:external/AlexanderTalledo/integrate-convention-plugins-into-version-catalogsfrom
AlexanderTalledo:integrate-convention-plugins-into-version-catalogs

Conversation

@AlexanderTalledo

@AlexanderTalledo AlexanderTalledo commented Mar 5, 2026

Copy link
Copy Markdown
Contributor

Checklist

  • If applicable, unit tests
  • If applicable, create follow-up issues for purchases-ios and hybrids

Motivation

While developers' priority is always the end-user, improving the development experience (DX) and making the daily workflow more comfortable for developers is equally vital. By integrating convention plugins into Version Catalogs we do unlock a lot of benefits for development with a very few small changes:

  • Standardization: If we already add third party's plugins via aliases, why should we add our plugins in a different way?
  • Single source of truth: libs.versions.toml is the only place to go.
  • Less error prone: Avoid failure builds because of a typo or misscopying the ID from somewhere else. This also safe us some time.
  • IDE capabilites: Enables those helpfull features that make our life easier.
    • Code auto-completion
    • Refactoring/renaming
    • Error highlighting
    • ctrl/cmd + click for jumping to definition or finding usages

Note: I did not create any associated issue because I did not find any category that matches the purpose of this PR. If this is mandatory, please do let me know and point to under what category should be created.

Description

Integrate convention plugins into Version Catalogs to enable typesafe alias accessors for locally registered custom convention plugins.

Changes

  • Declare gradle convention plugins registered in build-logic/convention/build.gradle.kts on gradle/libs.versions.toml.
  • Replace hardcoded convention plugins IDs across all modules by the equivalent typesafe alias accessors.
    • Before: id("revenuecat-android-application")
    • After: alias(libs.plugins.revenuecat.android.application)

Testing

  • Verified that all modules successfully build after switching from hardcoded IDs to aliases.

Note

Medium Risk
Touches Gradle configuration across multiple modules by changing how core convention plugins are applied, so mistakes would surface as build/IDE resolution failures. No runtime or library logic changes.

Overview
Standardizes application of internal RevenueCat convention plugins by moving their IDs into gradle/libs.versions.toml and using alias(libs.plugins...) accessors instead of hardcoded id("revenuecat-...").

Updates the affected app and library modules (purchases, ui/*, feature/*, examples/*, integration-tests, api-tester) to use the new catalog aliases for the same convention plugins.

Written by Cursor Bugbot for commit 7b1fe62. This will update automatically on new commits. Configure here.

@AlexanderTalledo AlexanderTalledo requested a review from a team as a code owner March 5, 2026 17:54
@AlexanderTalledo AlexanderTalledo force-pushed the integrate-convention-plugins-into-version-catalogs branch from f18cebd to 7b1fe62 Compare March 8, 2026 12:04

@cursor cursor Bot left a comment

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.

Cursor Bugbot has reviewed your changes and found 1 potential issue.

Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.

Comment thread gradle/libs.versions.toml
android-test = { id = "com.android.test", version.ref = "agp" }
baselineprofile = { id = "androidx.baselineprofile", version.ref = "baselineprofile" }
revenuecat-android-application = { id = "revenuecat-android-application" }
revenuecat-android-library = { id = "revenuecat-android-library" }

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.

Unused plugin catalog entry added but never referenced

Low Severity

The revenuecat-android-library entry is added to the version catalog but libs.plugins.revenuecat.android.library is never referenced in any build.gradle.kts file across the entire repository. The other three new entries (revenuecat-android-application, revenuecat-api-tester-application, revenuecat-public-library) all have corresponding usages, but this one does not — neither before nor after this PR. This introduces dead configuration that could confuse future developers.

Fix in Cursor Fix in Web

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

While it's true that revenuecat-android-library is not used at the moment, I decided to added as well to match the registered plugins on build-logic/convention/build.gradle.kts. Because I'm lack of context whether this plugin is going to be used in the near future or not, I just go with matching parity between registered convention plugins and the ones defined on Version Catalogs.

Let me know whether declaration should be removed from version catalogs or keep it there so it's already available if needed in the future

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.

It's indeed unused right now, and while it might be used in the future, we might want to remove it until then to avoid having unused code. We will handle that :) Thank you for letting us know!

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Fair enough. Thank you too for handling the unused plugin removal

@tonidero tonidero left a comment

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.

Thanks for the contribution! We will get this merged :)

@tonidero tonidero changed the base branch from main to external/AlexanderTalledo/integrate-convention-plugins-into-version-catalogs March 9, 2026 09:24
@tonidero tonidero merged commit 11f3cab into RevenueCat:external/AlexanderTalledo/integrate-convention-plugins-into-version-catalogs Mar 9, 2026
1 check passed
github-merge-queue Bot pushed a commit that referenced this pull request Mar 11, 2026
… contributed by @AlexanderTalledo (#3194)

<!-- Thank you for contributing to Purchases! Before pressing the
"Create Pull Request" button, please provide the following: -->

### Checklist
- [x] If applicable, unit tests
- [x] If applicable, create follow-up issues for `purchases-ios` and
hybrids

### Motivation
<!-- Why is this change required? What problem does it solve? -->
While developers' priority is always the end-user, improving the
development experience (DX) and making the daily workflow more
comfortable for developers is equally vital. By integrating convention
plugins into Version Catalogs we do unlock a lot of benefits for
development with a very few small changes:
- **Standardization**: If we already add third party's plugins via
aliases, why should we add our plugins in a different way?
- **Single source of truth**: `libs.versions.toml` is the only place to
go.
- **Less error prone**: Avoid failure builds because of a typo or
misscopying the ID from somewhere else. This also safe us some time.
- **IDE capabilites**: Enables those helpfull features that make our
life easier.
    - Code auto-completion
    - Refactoring/renaming
    - Error highlighting
    - `ctrl/cmd + click` for jumping to definition or finding usages
<!-- Please link to issues following this format: Resolves #999999 -->

**Note:** I did not create any associated issue because I did not find
any category that matches the purpose of this PR. If this is mandatory,
please do let me know and point to under what category should be
created.

### Description
Integrate convention plugins into Version Catalogs to enable typesafe
alias accessors for locally registered custom convention plugins.
#### Changes
- Declare gradle convention plugins registered in
`build-logic/convention/build.gradle.kts` on
`gradle/libs.versions.toml`.
- Replace hardcoded convention plugins IDs across all modules by the
equivalent typesafe alias accessors.
    - Before:  `id("revenuecat-android-application")`
    - After: `alias(libs.plugins.revenuecat.android.application)`
#### Testing
- Verified that all modules successfully build after switching from
hardcoded IDs to aliases.

contributed by @AlexanderTalledo in #3181

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> **Low Risk**
> Build configuration-only change that replaces plugin IDs with
version-catalog aliases; risk is limited to potential Gradle
misconfiguration causing build failures.
> 
> **Overview**
> **Gradle convention plugins are now sourced from the version
catalog.** The PR adds entries for RevenueCat’s locally-registered
convention plugins to `gradle/libs.versions.toml`.
> 
> All affected modules switch from `id("revenuecat-…")` to the type-safe
`alias(libs.plugins.revenuecat.… )` form (apps, libraries, samples, and
test modules), standardizing plugin application and centralizing plugin
IDs.
> 
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
11f3cab. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

Co-authored-by: Alexta <8045196+AlexanderTalledo@users.noreply.github.com>
This was referenced Mar 11, 2026
github-merge-queue Bot pushed a commit that referenced this pull request Mar 12, 2026
**This is an automatic release.**

## RevenueCat SDK
### ✨ New Features
* [EXPERIMENTAL]: Beta Galaxy Store Support (#2903) via Will Taylor
(@fire-at-will)
### 🐞 Bugfixes
* Skip installation on GCP CLI in run-firebase-test (#3218) via Will
Taylor (@fire-at-will)
* Fix reduced timeouts being used for HTTP requests when a proxy URL is
configured (#3188) via Rick (@rickvdl)

## RevenueCatUI SDK
### 🐞 Bugfixes
* Fix missing ripple effect in View-based paywall wrappers (#3206) via
Toni Rico (@tonidero)
### Paywallv2
#### ✨ New Features
* Rules v0 Integration branch (#3117) via Cesar de la Vega (@vegaro)

### 🔄 Other Changes
* [Galaxy]: Add promotionEligibilities comment (#3214) via Will Taylor
(@fire-at-will)
* [EXTERNAL] Migrate deprecated buildDir to layout API (#3202)
contributed by @AlexanderTalledo (#3212) via Toni Rico (@tonidero)
* Remove automatic Claude code review workflow (#3211) via Cesar de la
Vega (@vegaro)
* Remove unused convention plugin (#3195) via Toni Rico (@tonidero)
* [EXTERNAL] Integrate convention plugins into Version Catalogs (#3181)
contributed by @AlexanderTalledo (#3194) via Toni Rico (@tonidero)
* [EXTERNAL] Migrate androidx cardview dependency to version catalogs
(#3192) contributed by @AlenxanderTalledo (#3193) via Toni Rico
(@tonidero)
* Improve AdMob adapter test coverage (#3204) via Pol Miro (@polmiro)
* Bump fastlane-plugin-revenuecat_internal from `f5c099b` to `e146447`
(#3197) via dependabot[bot] (@dependabot[bot])
* Fix integration tests (#3196) via Toni Rico (@tonidero)

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> **Low Risk**
> Low risk release bookkeeping: version strings and deployment paths are
updated from `9.24.0-SNAPSHOT` to `9.24.0`, plus changelog/docs refresh.
Main risk is accidental publishing/docs deployment to the wrong
versioned location.
> 
> **Overview**
> Cuts the `9.24.0` release by updating all version references from
`9.24.0-SNAPSHOT` to `9.24.0` (root `.version`, `gradle.properties`, and
`Config.frameworkVersion`), and aligning sample/test app version
catalogs to consume the released artifact.
> 
> Updates documentation publishing to point at the `9.24.0` directory
(CircleCI S3 sync and `docs/index.html` redirect) and refreshes
`CHANGELOG.latest.md`/`CHANGELOG.md` with the `9.24.0` release notes.
> 
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
8e6d567. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
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.

2 participants