Non-"intermediary" AccessWideners are Unsupported when no Intermediary is Present in Production about fabric-loader

[Linguardium]

if you remap the entire game to mojmap in production, and then try to load mods that are mapped to intermediary (the production output state), that will never work. there is a reason floader remaps the game to intermediary and loom remaps mods to intermediary at build time. if you are deviating from that to force some other mapping, you need to go all the way and remap everything not just the base game

[Chocohead]

Loader expects AWs to be in the target namespace:

fabric-loader/src/main/java/net/fabricmc/loader/impl/FabricLoaderImpl.java

Line 527 in a2c5248

accessWidenerReader.read(reader, FabricLauncherBase.getLauncher().getTargetNamespace());

Knot presumes this is named in dev or intermediary out of dev:

fabric-loader/src/main/java/net/fabricmc/loader/impl/launch/knot/Knot.java

Lines 258 to 260 in a2c5248

	public String getTargetNamespace() {
	// TODO: Won't work outside of Yarn
	return IS_DEVELOPMENT ? "named" : "intermediary";

Loader only remaps AWs when in dev, and even then only from intermediary to the target namespace (i.e. Yarn).

---

official as a namespace is effectively a Minecraft specific invention; if you search for it, the only references are in MinecraftGameProvider and an old overload in GameProviderHelper, all in the context of remapping the original game jar. Regardless to whether your GameProvider remaps the game jar, the target namespace is taken as intermediary (out of dev).

[modmuss50]

I think this is a valid issue, currently both loom and loader cheat a bit when intermediaries arent present as use intermediary as the namespace, this is mostly becuase the work to support this hasnt been done. All of the loader APIs should support this just fine.

[halotroop2288]

Soooo... call it what it is. dev or production

Cause development isn't always "named" and production isn't always intermediary. It seems like that is the only necessary distinction here.