Mod Loader (Required)

Quilt

Minecraft Version (Required)

1.19.2, but affects latest too

Mod Version (Required)

4.2.9, but affect latest too

Notes (Required)

This occurred in a development environment but I verified the issue outside the dev env with both Quilt and Fabric.

From @lukebemish:

Basically, the issue here, best I can tell, to lay it out for posterity:

• Create bundles two non-mod deps (night config)
• Create bundles forge config port, and depends on it properly via maven
• Forge config port depends on the night config deps, and best I can tell declares that dep properly via maven
• ...but forge config port declares a dependency on the "generated" mods for the night config deps. In dev, the nightconfig deps are added the classpath - but they aren't turned into mods, since that's how dev envs with loom work (and yes, this is painful and I wish it could be changed but that's hard. Maybe for quilt gradle)

Forge config port's dependency section of their FMJ, for reference:

"depends": {
  "fabricloader": ">=0.14",
  "fabric": ">=0.55.1",
  "com_electronwill_night-config_core": "*",
  "com_electronwill_night-config_toml": "*",
  "minecraft": ">=1.19 <1.20",
  "java": ">=17"
}

Crash Report (Required)

https://paste.gg/p/anonymous/fd7c25f996f444d881dfa363d69871f2

latest.log (Optional)

No response

There unfortunately doesn't seem to be any way around having the bundled night config jars in the depends block.
I didn't have them there initially, and that was leading to the occasional java.lang.NoClassDefFoundError for Night Config classes when called from FCAP in case another mod was bundling Night Config, too, with a newer version, see FabricMC/fabric-loader#589.

To work around this I've made it so that the publication to my own Maven (https://raw.githubusercontent.com/Fuzss/modresources/main/maven/) does contain a different fabric.mod.json from the publication pushed to CF/Modrinth where there is no dependency set on Night Config jars, so that dependency overrides are not necessary in a development environment.

Create wouldn't have to use dependency overrides if it would simple use FCAP from my Maven instead of the CF Maven.

I'm open to suggestions in case the current approach regarding the publication on my Maven doesn't work out for you, but I definitely won't be removing Night Config dependencies from fabric.mod.json for the production jars pushed to CF/Modrinth since the initially mentioned issue will come back.

Note that create fabric appears to currently be using a dependency override to work around the same issue: https://github.com/Fabricators-of-Create/Create/blob/mc1.19/fabric/dev/run/config/fabric_loader_dependencies.json

Hmm. How early are you using nightconfig that specifying it as a dependency is necessary? Nightconfig stuff doesn't have any entrypoints, so the idea of load order shouldn't really matter, unless you've got some really early entrypoint or use of nightconfig stuff in a mixin config or something.

This is the crash I was repeatedly getting when the dependencies on Night Config were not specified: https://pastebin.com/qraiRUWq

The Beacon Overhaul mod was also bundling Night Config, but a newer version. So Fabric Loader would prefer that version over the Night Config jars bundled with FCAP, but wouldn't load them until Beacon Overhaul would load. Some of my mods depending on FCAP would load before Beacon Overhaul though and therefore trigger the java.lang.NoClassDefFoundError.

Anyways, why doesn't using FCAP from my Maven where there is no dependency set in fabric.mod.json work for you?

I verified the issue outside the dev env with both Quilt and Fabric.

@Oliver-makes-code Can you please elaborate what exactly you did there? Since FCAP bundles Night Config those libraries are present as proper Fabric mods in a production environment, so I'm not sure how they could possibly show up as missing mods.

loom isn't generating JiJ metadata

Which metadata specifically is missing?

wouldn't load them until Beacon Overhaul would load

As JiJed non mod deps don't have entrypoints, that doesn't really make sense; all mods are put on the classpath before any of them load (have their entrypoints fire), as far as I'm aware. I'm suspecting there's some actual issue, possibly on the loader end, that's gotten buried here; I'll do some digging and see what I can discover. It may be that the other mod in question is doing something funky in how it JiJs nightconfig or something; I'll dig into it and let you know what I find out.

I'm not the person consuming your mod, just someone who ended up helping with troubleshooting, so I can't say exactly why using your maven isn't great; generally speaking, though, some people don't like using too many different mavens to consume libraries from, as it means that there's more bits that could cause a build to fail if they're offline. I would say though that using your maven is probably a good solution, though it would be nice to see if we can't track down the root issue here.

Thanks for the input! A few more things I remember:

com/electronwill/nightconfig/toml/TomlFormat (the class causing java.lang.NoClassDefFoundError in the crash) definitely existed, so it's not like it was removed/moved between v3.6.3 (the jars bundled with FCAP) and v3.6.5 (the jars bundled with Beacon Overhaul that ended up being used by Fabric Loader in favor of the ones bundled with FCAP) of Night Config, I specifically checked that.

Also although Beacon Overhaul was bundling Night Config it didn't actually use it, it didn't have it as a dependency in fabric.mod.json and also didn't call any classes from it.

Hmm. Do you have a link to the beacon overhaul version in question? Because, basically, mods are all "loaded" (on the classpath) before any entrypoints are run, so this sort of thing should be impossible - especially because JiJed stuff is loaded if_present (so, if there's any version of a given dependency JiJed); this leads me to suspect that there's something a bit wackier going on here with how loader is behaving. I'll see if I can find anything out; if loader is indeed acting that way, that ought to be considered a loader bug.

A way this could be fixed is by shadowing nightconfig in your jar

So yeah, using a shadow configuration is what I ended up going with for the 1.20 release.
Feel free to tell me if you find any new issues with that. Otherwise I'll consider this closed.

Not sure yet about backporting this change to older versions, want to definitely wait a little before that to see if any issues arise, especially with other mods that ship Night Config as Jar-in-Jar.