Fabric API is supposed to be modular. This means that mod devs should be able to pick and choose which Fabric API modules to depend on in their mods, both in the development environment and in production.
Fabric API is also supposed to be just another mod. Fabric API should not have special support in Fabric tooling, nor should it be a required install for players. Basically, Fabric API is simply a collection of mostly independent modules that happen to be maintained by the same organization that maintains Fabric tooling.
The fabric example mod contains a hard dependency on the entire Fabric API. Since most mod devs do not remove this dependency, most players have to download an additional mod (Fabric API) in order to play a Fabric mod, which many players do not expect. This means mod devs often assume that players have installed Fabric API in the production evnironment.
The reason that most mod devs do not depend on and include the specific Fabric API modules they use is twofold.
- Depending on the entire Fabric API is the default provided in the fabric example mod
- Depending on specific modules is difficult because the modules do not have Minecraft version information attached
I have been told that module versions that differ only in metadata are correctly de-duplicated by Fabric Loader at runtime, so that is no longer an issue.
My proposed solution does not change the Fabric landscape much. Instead, it touches API and the example mod in small ways that make depending on API modules easier and should gradually phase out the need for players to download the full API.
- Remove
"fabric": "*"from example mod'sfabric.mod.json - Remove fabric API dependency from example mod's
build.gradle - Encourage mod devs to depend on and
includethe specific Fabric API modules they need - Add the Minecraft version API modules were built against to the module version metadata
- Add configuration to the
includedirective to produce a flattened JIJ- Mods that include several libraries would not need to store duplicate JIJ dependencies.
I assume here that most mods depend on a small number of API modules. For example, my own mod Structure Helpers depends on only three API modules (Resource Loader, BE Networking, and Networking). The Luminiferous Uplands may be an example of an extensive content mod, and even it uses only 10 of the Fabric API's 30 modules (Resource Loader, Object Builders, Content Registries, Tool Tags, BE Networking, Dimension, Render Layers, Rendering Registry, Item Groups, and Container). Users should therefore see fewer unused modifications in standalone mods, and most mod devs should see smaller development environments.
Every mod that includes assets or data requires Resource Loader. Additionally, every mod that adds content to the vanilla registries requires Registry Sync. I propose that the mods that require these modules include them anyway (even if almost every mod needs it). Modpack developers can handle de-duplication and the two API modules should be small enough not to impact download size much. An alternative is not to include these two modules and to require players to download these two modules separately. This second option is obviously more work for the player.
Here, I examine a few of the proposed solutions and the disadvantages to them.
Add Fabic API module support to Loom (Loom PR #183)
This PR adds support into Loom to automatically fetch Fabric API modules specific to a Fabric API fat version. This solves the problem of determining which API modules to depend on, but it adds Fabric API specific behavior into Loom. Loom should not have to cater to the structure of the Fabric API.
This would automatically determine the (transitive) dependencies required in a mod and include them in the mod jar automatically. This means mod devs do not have to depend on specific API modules. However, it is non-trivial to determine whether a dependency is used or not, and there is no PR yet which adds this functionality.
Alert Players to Install Fabric API (Fabric Installer PR #38)
This sidesteps the development issue and instead attempts to educate players about the current system. This proposal often includes messages in Fabric Loader or the Fabric Installer telling players to install Fabric API. This is undesirable because it elevates Fabric API to special status in the view of the player, may cause the player to download Fabric API when it is not needed, and is a maintainance burden for the Fabric tooling that otherwise does not need to be aware of Fabric API.
Good writeup. Personally I would add that special-casing in loom is less problematic than special-casing in the loader/installer/user manual install guides, as I believe the main issue is modders relying on users to have Fabric API in their installation by default. Also gradle plugins supporting other libraries can be made and distributed quite easily.