[Feature] support fabric's loom `fabricApi` module with in dependency block

[Skidamek]

Hi, I am transforming my project from architectury loom to the modstitch it seems to mostly work great (with the patches applied from latest commits - please, upload snapshots to the maven)
However what i could do with the architectury loom or just plain fabric loom is to JiJ specific fabric modules easily like:

setOf(
    "fabric-api-base",
    "fabric-resource-loader-v0",
    "fabric-registry-sync-v0",
    "fabric-networking-api-v1"
).forEach {
    include(modImplementation(fabricApi.module(it, property("fabric_api_version") as String)))
}

I tried that within dependencies.modstitch.loom but no luck. It prints Unresolved reference: fabricApi error.

It wouldn't be needed if fabric api modules would inherit the same version number as the whole fabric api bundle, unfortunately the modules use some quite random to me number versions like e.g. fabric-api-base module within fabric api 0.127.1+1.21.6 has version 0.4.63. It would be a pain to manually check each version for each module in multi-version project.

[Kira-NT]

So, modstitch.loom is basically just a method that executes a delegate provided to it if and only if the currently selected platform is loom. In order to actually get into real Loom's context you want to do this instead:

dependencies {
    modstitch.loom {
        configureLoom {
            // Here you'll be able to access the `fabricApi` stuff you are looking for
        }
    }
}

A little bit cumbersome and wordy, I know, but it should work. I guess we could proxy the original LoomGradleExtensionAPI to remove this extra step? I'll look into it a bit later.

[Kira-NT]

Welp, proxying LoomGradleExtensionAPI should be pretty straightforward, since it's an interface. On the other hand, though, MDG's ModDevExtension is an abstract class, which makes it impossible to proxy via standard methods, and I'm not sure if I wanna go with the cursed ones...

[isXander]

At least for now, you can use the BOM that is published by Fabric.

dependencies {
  modImplementation(platform("net.fabricmc.fabric-api:fabric-api-bom:VERSION"))
  modImplementation("net.fabricmc.fabric-api:fabric-api-lookup-api-v1") // version is from BOM
}

you can obviously kotlin-ify this with a forEach etc.

[Kira-NT]

@isXander, btw, what do you think about "fusing" configureLoom and configureNeoforge with their containing interfaces? For example, BaseLoomExtension could look like this:

interface BaseLoomExtension : LoomGradleExtensionAPI {
    val fabricLoaderVersion: Property<String>
}

With this, folks won't need to write:

modstitch {
    loom {
        configureLoom {
        }
    }
}

and such. Just modstitch.loom and modstitch.moddevgradle would be enough.

The only problem is we cannot inherit nicely from MDG's ModDevExtension, since it's a class, not an interface. Thankfully, it doesn't contain too many methods, so we could just mimic its structure?

[Skidamek]

Even with nested configureLoom it doesn't work

At least for now, you can use the BOM that is published by Fabric.

dependencies {
modImplementation(platform("net.fabricmc.fabric-api:fabric-api-bom:VERSION"))
modImplementation("net.fabricmc.fabric-api:fabric-api-lookup-api-v1") // version is from BOM
}

you can obviously kotlin-ify this with a forEach etc.

That did the trick, thanks!

[Skidamek]

But problem is that they only started making the BOM builds from 1.20.4...

[Kira-NT]

Even with nested configureLoom it doesn't work

Oh, my bad. I assumed fabricApi was a property on LoomGradleExtensionAPI, however it's its own extension, which is obviously missing whenever you target (Neo)Forge, hence the complains from the compiler. Yeah, in this case, it does make perfect sense to shadow fabricApi and other Fabric-related extensions (if any) within the Modstitch's loom block