The modularization of the Fabric API has gone too far

The title says it all. We currently have 42 modules in the Fabric API. Often times these modules have somewhat of an overlaping scope. I propose a massive refactor to reduce the number of modules, remove the deprecated modules, and propose higher scrutiny for new modules. Looking through the modules, they often only have a handful of classes, and should be merged into other modules. My proposed modules: module: existing modules to include item : item, itemgroup, tool-attribute, mining-levels, the item section of object-builder (model predicate providers) block: block-render-layer, block section of object-builder, container entity: entity-events, villager parts of object-builder world: biome, dimension, structure, gamerule, (command?), loot-tables, advancements section of object-builder lifecycle: lifecycle, (command?) rendering: all rendering apis, particles, textures, models client: keybinds screen: screen, screen-handler registry: registry-sync

Modules that stay: resource-loader, networking, tag-extensions, crash-reports, and base

This list may not be complete, but i think reducing the number of modules will be an important part of the fabric API moving forward

[LambdAurora]

I agree with most.

But I entirely disagree with the rendering part, renderer-api should stay separate from the other rendering stuff.

[liach]

Another criteria for grouping modules imo would be allowing them to break in updates. I hope this can be considered when we try to merge modules, i.e. don’t merge frequently changed modules with relatively stable modules. Biomes can stay as it blows up often given mojang’s frequent updates.