Let's Talk: Modularization

[LemmaEOF]

Right now, LibCD is starting to get a bit bloated. It's fundamentally just two things, data extensions and tweakers, but each of those have a lot of subfeatures. On the extensions side, there's condition mcmetas, in-tag conditions, default tag entries, default tag entry output in both recipes and loot tables, and support for full item stack objects in cooking and cutting recipes. On the tweaker side, there's the recipe tweaker, custom-behavior crafting recipes, and loot tweakers, including a lot of builders. It's getting to be a lot for a single lib, but I'm not entirely sure the best way to safely split it up. If anyone has ideas, please let me know!

[LemmaEOF]

At the very least, I want to have it so you can have just the API in your dev environment so you don't need to depend on the whole thing. However, I'm a bit worried I messed the ability for that up when I set up the TagHelper class in the way I did. I don't really know how to fix that.

[falseresync]

Maybe TagHelper.ITEM -> ItemTagHelper.INSTANCE?

[falseresync]

You may also shard API into pieces shipped only with certain modules, like CCA does

[LemmaEOF]

well the issue is that ItemTagHelper.INSTANCE has methods that I don't want exposed publicly, which is why the interface exists in the first place.

[Pyrofab]

I think there should be a dedicated tag module. Personally I use LibCD in my mods to add modded entries to my tags, so I don't really need anything else.

[LemmaEOF]

The thing is that tag extensions depend on both conditions and default entries. I'm not sure whether it would be a good idea to have .mcmeta and the recipe/loot table default-entry extensions in the tag module. Everything's super tangled up because I'm honestly not the best API dev.

[falseresync]

You should probably make a dependency graph for your API, that would give you a visual aid of what you're trying to do