When the vanilla datapack references a list of something and mods want to modify said list, comparability issues often arise. In all of those cases, the vanilla schemas allow this list to be specified as a tag, but vanilla often doesn't use an adequately specialized tag. This has come up a couple of times now, so I think it is time to figure out a proper general solution to this issue.

This issue is especially tricky as the comparability issue also comes up outside the fabric ecosystem, as they are all related to vanilla datapack behavior.

List of current cases

As mojang makes more and more features data-driven this situation will come up more often in the future. These are the cases I'm aware of currently:

Wolf variants

(discussed in #3701)
Wolf variant specify which biomes they should spawn in. However the vanilla wolf variants either specify a general tag (such as #minecraft:is_forest; also used for strucutre placement), or a single biome. Adding a wolf variant to a custom biome requires modifying the wolf variant to use a tag, leading to compatability issues if different tags are used.

Enchantments

Enchantments specify lists of items for primary_items and supported_items. However in vanilla multiple enchantments often share a item tag, such as #minecraft:enchantable/sword making it difficult to allow a specific enchantment of custom items.

Farm animal variants (speculative)

25w02a added pig variants that use #minecraft:spawns_cold_variant_farm_animals and #minecraft:spawns_warm_variant_farm_animals biome tags, leading to the speculative option of other farm animal variants reusing these tags, causing problems if a custom biome is supposed to spawn cold pigs but warm cows.

Biome features / carvers

(this is a very old issue and I'm not proposing doing anything about this here, I'm just adding it for completeness)

Biomes specify lists of placed features to place in the biome. The schema does allow this to be done with placed feature tags, but the vanilla data doesn't make use of this. Fabric provides a code based API to add placed features to biomes, but datapacks have to override the biome file to achieve this, leading to comparability issues.

Possible solutions

(copied and modified from post by @TelepathicGrunt in #3701 (comment))

Solution 1:

Agree on c tags to use and override the json files in Fabric API to make them use it. Datapackers will need to copy modloaders to make their datapack work out of the box with mods. A datapack/mod that doesn't do this can easily break all other mods. When the json file is often modified for other purposes, the likelihood of a datapacke author not using the c tags is greatly increased.

Solution 2:

Agree on a c tag but do not override the json files in Fabric API. Mods and datapacks both would need to replace the variant json themselves to make it point to this c tag. When the json file is often modified for other purposes, other mods would regularly undo changes by lower packs.

Solution 3:

Agree on a c tag, and modify the data after all datapacks are loaded to make them use the tag. This way it is guaranteed that things added to the tag will be used. Datapack authors can still add the tag manually for the datapack to work in vanilla and use the tag as a standard for inter-datapack compatibility, but datapacks using something different don't break fabric mods. Dynamic modification of data can result in opaque behavior.

Solution 4:

Provide a code based API or rely on mods using mixins. Datapacks would not benefit from any comparability between each other, but mods are able to add to whatever a datapack sets.