idiomatic-gradle VS Gradle buildSrcVersions

You should look into how https://github.com/jjohannes/idiomatic-gradle and similar projects handle it (nowinandroid has a good set up as well).

And finally, look at the idiomatic gradle repo. There is also a free video series that goes with this Understanding Gradle – Video Series. There are lots of bad practices in gradle that will slow your builds down, like using allProjects {}

I'd suggest getting rid of buildSrc, and just using build composition. I mentioned in another response, but check out https://github.com/jjohannes/idiomatic-gradle for how to use precompiled script plugins that are connected to the project via includedBuilds. The only issues I've had with this are generally resolved by just running the sub-build independently to resolve any caching issues in the 'primary' build. A simple gradlew build --settings-file ./build-logic/settings.gradle.kts run will generally resolve that, and that issue seems largely because of the 'root' build being a peer or anscestor of the included build (due to legacy structure of the project, an issue the linked example repo does not have).

When we initially migrated from buildSrc to an included build, it seemed an elegant solution to the problems outlined above. We were dropping buildSrc, with all its problems, and using the modern facility that Gradle considers the preferred, idiomatic replacement for buildSrc. (For a very elaborate example of this, see the idiomatic-gradle repo by former Gradle engineer Jendrik Johannes.) Included builds are indeed the best of both worlds in many ways: they can exist under version control in the same repository as the build that uses them; they can be easily opened in a separate IDE instance, improving build engineer productivity; they don't have the automatic test behavior of buildSrc, which improves feature engineer performance; and they're generally very well-behaved, without any of the magic of buildSrc.

Lately I've been using gradle with kotlin-js and a mix of npm and jvm dependencies. There's the https://splitties.github.io/refreshVersions/ plugin that I can recommend if you are using gradle (with or without kotlin-js).

It manages plugin dependencies, library dependencies, and version dependencies. It can use the new gradle version catalog or not if you prefer. On first use, you migrate your versions and it extracts these to a versions.properties (or your version catalog). Then whenever you run refreshVersions it indicates available new versions in comments in this file. It also indicates unused dependencies. Though for npms this is a bit harder. All you need to do is manually use the versions you want.

I run this frequently to stay on top of upstream changes. Few software engineers realize that the testing and integration overhead with version changes multiplies (just like with other forms of change). Libraries that you haven't updated amount to technical debt that you haven't addressed. So, the workload increases massively if you don't update for a while. Staying up to date minimizes the workload. This plugin makes that super easy.

Given that we are using kotlin-js, we have to deal with a rapidly evolving library ecosystem so we do have occasional issues that we need to work around by either downgrading or fixing some code. Whenever I can't update something, I document it in my versions.properties with a comment. Often you just have to wait for the next release or so for things to straighten out. The price of using cutting edge software.

Kotlin-js manages a yarn lock file as well. So it properly locks dependencies. Whenever you update npm dependencies, you have to run a command to upgrade the lock file. There's also a whole mess of webpack dependencies that comes along with kotlin-js.

{$% embed https://github.com/splitties/refreshVersions %}

I need a Gradle plugin for managing version upgrades for dependencies. I used refreshVersions; however, I don't like how those dependencies end up in multiple files, e.g., versions.properties vs lib.versions.toml. I want something simpler. So, what do you prefer?

As somebody with a deep personal hatred of TOML I recommend refreshVersions https://github.com/jmfayard/refreshVersions just a million times better and will support version catalogs soon maybe

refreshVersions, it is literally the best

Note that I'm using gradle refreshVersions to make it easy to keep the project up-to-date. Therefore, the versions are not defined in the build.gradle files, they are centralized in the versions.properties file. RefreshVersions is bootstrapped like this in settings.gradle.kts:

Also the official sample for gradle refreshVersions