FMJv2 will be a breaking change to FMJv1 with several incompatible changes.
Forge uses a TOML file, mods.toml, instead of JSON. Forge mod metadata file is very small, and all features except update check URL exist in FMJv1. Update checking should NOT be included in FMJv2, as that is beyond the scope of Fabric API/Loader. Mod Menu might be able to implement it.
Therefore, no feature from Forge metadata is worth bringing over.
Spigot is not a modloader, but uses plugin.yml (YAML file) in a similar way. Apart from common fields:
- Since Spigot is designed to be API-based with plugin compatibility in mind, it allows API version to be specified. Inapplicable to Fabric.
loadfield can change when the plugin loads, either startup or world load. The concept does not apply neatly to Fabric as it supports clients as well as dedicated servers. Fabric Lifecycle Events provides similar functionality.prefixspecifies the prefix used by logging. Since most, if not all, Fabric mods use the class name as the prefix, this is not a huge priority, and I am unsure if Fabric Loader can change this.softdependdeclares "soft dependency", i.e. non-required dependency. This corresponds tosuggests.loadbeforespecifies the loading order. However, it is pretty clear Fabric does not take this approach.librariespreview feature allows plugins to load Maven Central libraries. Fabric Loader is designed to work offline, so this is inapplicable.commandsdeclares registered commands. Fabric API provides this instead.permissionsdeclares permissions. Fabric mods usually use the vanilla permission level mechanics or uses a common unofficial mods.
Therefore, no feature from Spigot metadata is worth bringing over (aside from prefix, if it works at all).
It seems like Sponge actually used annotations to define plugin metadata; however, the documentation mentions that JSON metadata is available in Sponge 8+. That said, Sponge offers several interesting fields:
loaderspecifies the loader version. This does exist in FMJv1, but is interesting nonetheless since others don't have this.mappingsspecifies the used mappings. While Fabric mods are usually distributed with intermediary, this might be worth adding because of alternative mappings (e.g. Hashed-Mojmap) or for development environments where named mappings are used. Fabric Loader can exit early if the mapping is unsupported, which can reduce confusion from using dev jars in production.globalspecifies global settings. Since a Sponge plugin can bundle multiple plugins (sort of like FAPI I think?) this applies to all plugins in it unless explicitly stated.global.brandingcontainslogoandicon. This is unlike FMJv1 which only specifiesicon. Not sure iflogois useful.global.dependenciescan specify the dependency load order, which as I said is inapplicable to us.
mappings is the only change which could be worth porting to FMJv2.
I couldn't find the documentation for quilt.mod.json, so I had to reverse-enginner the code.
pluginsis probably for "loader plugins" which is not a thing in FL yet.repositories: undocumented, not sure what the use is.load_type:always,if_possible, orif_required. Mods in mod folder always load regardless; this affects JiJ.intermediate_mappingsspecifies the intermediary mapping used, similar to Sponge'smappings.metadata: Metadataception. ah yes. This contains the mod's name, contributors, etc.mixin: for some reason, they made this singular. Why.minecraftcorresponds toenvironmentin FMJ. However, the field rename is not something I'd suggest, since FL itself is not Minecraft-exclusive. Another change is use ofdedicated_serverinstead of FMJ'sserver; this change should be ported as "server" is ambiguous.dependshad several changes. First, this is an array instead of an object. The array can have a string to represent any version, or an object withidandversionsfield. There is alsooptionalfield to declare if the dependency is optional (not sure what the difference betweensuggestsis),reasonstring field, andunlessfield which I'm also unsure what the intended usage is. Versions are specified as one string or an array of strings ANDed.
Fabric should add the enhanced dependency declaration (except for unless and optional), rename server to dedicated_server within environment without renaminng the field, add intermediary field (see Sponge section), and potentially add load_type support.
It should be possible to specify multiple access wideners, potentially with side designation, like mixins:
{
"accessWidener": [
"modid.accesswidener",
{
"environment": "client",
"file": "modid.client.accesswidener"
}
]
}Strings should also continue to work.
When building, Loom automatically grabs dependency info from dependency jar's FMJ file, including its name, version, and URL. These should be appended to the dependent's FMJ file. FL can use this information to make the "missing dependency" screen more detailed.
The QMJ spec is here: https://github.com/QuiltMC/rfcs/blob/main/specification/0002-quilt.mod.json.md.
mixinis singular because the top-level of QMJ is supposed to be mod ids (the key isn'tmixinsas in "here's my mixins", butmixinas in "here's the data to give to the mixin library". This is what we do instead of having a specificcustomblock.It's also worth noting that, following this philosophy, Quilt Loom uses a slightly different format for the custom values for interface injection and provided javadoc, like this:
{ "quilt_loader": {...}, "quilt_loom": { "injected_interfaces": {...}, "provided_javadoc": "some_path" } }