Kir-Antipov
commented
6 months ago The feature you are asking for has always been here. Default values, including those generated by auto-detection, are only utilized if you haven't provided a value yourself. If you prefer to have no dependencies shown on your project's page at all, you can supply an empty "array" (i.e., an empty string, since GitHub does not allow complex values to be passed to actions) to mc-publish, and it will happily use it:
dependencies: ""However, I would argue against completely nuking this valuable information, which could be useful to fellow users and automation tools alike. If you are opposed to fabric-api appearing as a dependency that your project relies on (even though it clearly does), you can easily disregard that specific dependency:
"custom": {
"mc-publish": {
"dependencies": [
// At present, Fabric has a somewhat limited dependency format,
// so, unfortunately, we aren't able to attach custom metadata to
// dependency entries directly.
// However, we can specify an additional dependency list in the
// top-level "custom.mc-publish" field, which will be merged
// with other, "traditional" dependencies.
//
// Note that you should use either "fabric" or "fabric-api",
// depending on the alias you used to declare
// a regular dependency entry.
"fabric-api#(ignore)"
]
}
}While I believe your question is answered, there's a larger discussion to have here. v4, which I am currently actively working on, focuses on supporting the entire spectrum of Minecraft-related projects: from mods, which are the only category that is fully-ish supported at the moment, to things like datapacks and plugins. I myself am a fairly simple man - I write Fabric mods for fun and don't care about anything else. However, for mc-publish's needs, I continuously research other project types and emerging development trends within the community.
Recently (not really), a number of mods started using Forgix, following Distant Horizons' lead, to merge all their mod loader-specific jars into a single one. While Forgix is quite cool as a proof-of-concept, I find the whole idea a little bit confusing. More specifically, I am unable to find an answer to the simple question "why?"
Sure, it somewhat makes sense in terms of Distant Horizons - it's yet another unusual thing standing out about the mod, which is more about artistic expression than actual functionality. Just as with Sodium, where Jelly wanted to make a beautifully-out-of-place settings screen as one of the mod's unique selling points, and no one could tell them otherwise. But what about other projects that now incorporate Forgix into their toolchain? What benefits does it provide them?
The only benefit that Forgix claims on its GitHub page is "you don’t have to worry about which mod-loader you’re installing for", which is debatable to say the least. Users (or the tools they use) nevertheless need to be aware of the mod loader they're using, as they still need to confirm that your mod is compatible with it. It doesn't really change anything from the user's perspective, at least not positively, whether your jars are merged or not.
Conversely, users now have to download a larger jar with unnecessary (for them specifically) components. Granted, this point might be negligible given that jar files are already oversized, and as people often remind me, "disk space is cheap" (with "if you live in a First World country" left silent). However, most importantly, it breeds confusion, as your very own case demonstrates nicely.
You are absolutely correct that fabric-api is irrelevant for (neo)forge. But how about the other way around? It is extremely relevent for the Fabric version of your mod, so relevant in fact, that if a user hasn't installed it, the game won't launch. So, should fabric-api be included in the list of your mod's dependencies? I don't have a good answer to that, as any solution only causes problems in the end. In this specific case, you might get away with not listing fabric-api as a dependency of your mod, because usually people download it alongside other mods, which also often require fabric-api and make this dependency known, so, most of the time, your unspecified dependency requirement will be satisfied. But is this really a good solution that can be applied to any project? I don't think it is, particularly when considering automation, which unlike humans, needs all dependencies to be explicitly defined in order to function correctly.
So those are my thoughts on the subject. I would like to hear your opinion on those! Why did you choose Forgix? Would you use it for a project with a greater discrepancy (in terms of dependencies) between different versions of your mod? Should mc-publish support merged jars and, if so, what sort of behavior would you personally expect out of the box?
Faboslav
Description
Turn off auto detection of dependencies
Alternative Solutions
No response
Risks
No risks
Other Information
I am releasing one file which supports all mod loaders, for example fabric, forge, quilt and neoforge, i dont have any defined dependencies in my github action, but there is fabric api automatically added, which cant be true for neoforge or forge.