Support a standardised set of gradle properties for automatic configuration

[isXander]

In a typical configuration, you may have a modstitch setup like this:

modstitch {
  findProperty("deps.fabricLoader")?.let { fabricLoaderVersion = it }
  // etc
}

deps.fabricLoader=0.16.14

I propose a standard set of gradle properties that automatically apply to modstitch, to reduce boilerplate even further. Of course, this would be optional.

[Kira-NT]

I think we could look for modstitch.* properties that mirror those defined on the ModstitchExtension:

modstitch.platform=loom
modstitch.fabricLoaderVersion=0.16.14
modstitch.modLoaderVersion=0.16.14 # The same thing as fabricLoaderVersion in this context
modstitch.minecraftVersion=1.21.6
modstitch.parchment.mappingsVersion=2024.12.29
# etc.

[Kira-NT]

Hm, as an idea, we could also support mod.* properties. While entries like mod.id would simply serve as a shorter version of modstitch.metadata.modId, there's an interesting possibility of automatically registering dependencies, for example:

mod.dependencies.modrinth.cloth-config=19.0.147+neoforge
mod.dependencies.modrinth.sodium=mc1.21.6-0.6.13-neoforge

Modstitch already acknowledges the existence of Modrinth and CurseMaven and adds their Maven repositories to the user's project by default, so I see this as the next logical step. With this approach, in most common scenarios, users wouldn't even need to specify anything in their build.gradle(.kts), allowing their projects to be entirely ✨data-driven✨

[isXander]

Hm, as an idea, we could also support mod.* properties. While entries like mod.id would simply serve as a shorter version of modstitch.metadata.modId, there's an interesting possibility of automatically registering dependencies, for example:

mod.dependencies.modrinth.cloth-config=19.0.147+neoforge
mod.dependencies.modrinth.sodium=mc1.21.6-0.6.13-neoforge
Modstitch already acknowledges the existence of Modrinth and CurseMaven and adds their Maven repositories to the user's project by default, so I see this as the next logical step. With this approach, in most common scenarios, users wouldn't even need to specify anything in their build.gradle(.kts), allowing their projects to be entirely ✨data-driven✨

This promotes the use of Modrinth and Curse mavens when the author-provided one should be preferred instead, which includes sources.

[Kira-NT]

This promotes the use of Modrinth and Curse mavens when the author-provided one should be preferred instead, which includes sources.

True, but first of all, there aren't that many author-provided Maven repositories to begin with - I can count them on my fingers, and yours is one of them. So, in the vast majority of cases where you're working on compatibility with another mod (take, for example, a small indie mod nobody's heard of, which also doesn't have its own Maven repo at the time of writing - Sodium), Modrinth's Maven is probably your best bet.

Secondly, and arguably more importantly, even when a mod does have its own repo, it's often a mess: packages might change names multiple times during their lifespan; the repo owner might rearrange things within their package kingdom, forcing you to dig out the artifact you need from an entirely new location; and some versions might simply be missing from the repo, even though they're clearly available on Modrinth.

I nearly went insane trying to keep up with all the changes in Cloth Config's repo in a multi-version setup. Eventually, I gave up on wiring up their Maven repo entirely and just fetched cloth directly from Modrinth, and my life became a bit easier after that.

Anyways, Cloth Config rant aside, we could introduce a common syntax for specifying the source of a requested package. For example:

mod.dependencies.required=cloth-config:4.6.0+fabric # Will be fetched from Modrinth by default
mod.dependencies.required=maven.fabricmc.net@net.fabricmc.fabric-api:fabric-api:0.128.2+1.21.7

With something like this, we could also automatically add dependencies to a mod's manifest!