What happened?

Fabric loader itself complaining about unsupported entires in betterstats's fabric.mod.json file.
See the logs for more info.

Steps to reproduce

Simply launch the game and check the logs.

Relevant log output or crash report

[16:09:14] [main/INFO]:
 Loading Minecraft 1.20.5 with Fabric Loader 0.15.10
[16:09:14] [ForkJoinPool-1-worker-2/WARN]:
 The mod "betterstats" contains invalid entries in its mod json:
- Unsupported root entry "" at line 26 column 4
- Unsupported root entry "" at line 26 column 86
- Unsupported root entry "" at line 28 column 4
- Unsupported root entry "" at line 28 column 88
[16:09:14] [ForkJoinPool-1-worker-2/WARN]:
 The mod "tcdcommons" contains invalid entries in its mod json:
- Unsupported root entry "" at line 27 column 4
- Unsupported root entry "" at line 27 column 192
- Unsupported root entry "" at line 29 column 4
- Unsupported root entry "" at line 29 column 24

Other installed mods

N/A

Code of Conduct

• I agree that if the issue is regarding a crash, I gave the logs and the crash report.
• I agree that I will be available later for any follow-up questions to help diagnose and resolve the issue.

Basically, my mods, like many other mods, have a bunch of Mixins. A Mixin is a component that allows a mod to inject its own code into the game's code. This is the primary way mods mod the game (given the game has no such thing as a "modding API" anyways, so there's really no other way but Mixins). Other than mixins, BSS has had TCDC embedded into it.

Now, in order for mixins and embedded jar file to work, they have to be explicitly mentioned in fabric.mod.json, hence why this gets veeeery annonying to deal with when frequent changes are made to mixins and embedded jars during development, as those changes have to be reflected in the fabric.mod.json (aka you gotta update the json file each time). This has lead me to just simply code gradle to "automate" the process, by automatically reflecting the changes in the fabric.mod.json.

I eventually did it by doing this in the fabric.mod.json, which would have automated this process for me:

{
    "mixins": ${project.ext.fmj_mixins},
    "jars": ${project.ext.fmj_jars}
}

Now this would have worked fine if everything went well, but uh oh, this is where I ran into a compiler issue. For some weird and completely stupid reason, the compiler validates the json file BEFORE handling the template literals (template literals are the ${...} thingies). This means that the compiler kept throwing errors at me, saying the JSON's invalid, even tho it'd've been completely valid if they just parsed and handled the template literals first, and only then validated the JSON.

Because of this, I was forced to do a work-around, where I placed template literals inside of a JSON string, and the template literals would then use a clever mechanism where they "break out of" the string by surrounding themselves with the "":"" entries (the ones we're seeing be complained about in the console). And this worked well. It was great. But then Fabric decided to pull off an extra "screw you moment", and they implemented logic that complains about those entries in the console.

Now here's the workaround I did; Instead of "mixins": ${project.ext.fmj_mixins}, I did the following:
"": "${project.ext.fmj_mixins}",
after which my gradle script would make the template literal escape the string by essentially pulling this off:

But as we can see here, this comes at a cost of the entry having to surround itself with the "":"" thingies that Fabric is complaining about in the console.

Now, will I be fixing this by reverting away from automation?
The short answer is no. Personally, I do not wish to fix a """flaw""" on my end, when the real flaws (in my opinion) are in the compiler and Fabric itself. Once the compiler starts actually behaving properly, and handles template literals before JSON validation, is where I'll no longer be forced into doing this weird loophole thingy.

Edit: typo fixes