Properly defining a mod metadata format

As you might’ve noticed, in 0.1.x-0.3.x the fabric.mod.json format is effectively “defined” by the Java class - this doesn’t really make for good documentation or specification.

This is an issue opened to discuss things which should be covered by a fabric.mod.json standard (“schemaVersion”: 1) which I hope to add in 0.4.0 - with the prior JSON files being implied as “schemaVersion”: 0.

These are the existing fields in the mod.json format as of 0.3.6:

	// Required
	private String id;
	private String version;

	// Optional (environment)
	private DependencyMap requires = new DependencyMap();
	private DependencyMap conflicts = new DependencyMap();
	private String languageAdapter = "net.fabricmc.loader.language.JavaLanguageAdapter";
	private Mixins mixins = Mixins.EMPTY;
	private Side side = Side.UNIVERSAL;
	private boolean lazilyLoaded = false;
	private String initializer;
	private String[] initializers;

	// Optional (metadata)
	private String name;
	private String description = "";
	private Links links = Links.EMPTY;
	private DependencyMap recommends = new DependencyMap();
	private Person[] authors = new Person[0];
	private Person[] contributors = new Person[0];
	private String license = "";

Some prior art:

• Forge/Sponge’s mcmod.info (duh)
• craftson spec - this is what we based the initial mod.json format on back in 2016, but have since deviated
• Spigot’s plugin.yml
• MCubed’s craft.json - designed for project formats, but could be useful here

I’d also like to call in @peterix as he might have lots of prior art from his work on MultiMC.

[Prospector]

Get rid of the single initializer in favor of the array.

[asiekierka]

We still need the adapter info.

Here’s a new proposal:

"entrypoints": [
    {
        "type": "main",
        "adapter": "default",
        "values": [
            "my/package/MyClass",
            "my/package/MyOtherClass::myMethod"
        ]
    }
}