[RFC] Reorganize location of modules in repository structure

At the time of writing, Fabric API has 39+ modules which definitely clutter the root folder of the repository. Among these 39 modules, 11 are client only, 7 are deprecated, 1 is experimental and 1 has not been updated yet. There is currently no real way to discern between these types of modules without opening each of them up.

The proposal

The modules shall be organized into 5 main categories:

• client
• common
• server
• deprecated
• experimental

Each category will have it’s own folder in the root of the repository and modules contained in the category would be resolved via project dir relocation.

The client and common categories will contain a majority of the modules, where the client category contains modules which are only loaded when running a Minecraft client and common for modules designed for use on a Minecraft client and dedicated server.

The server category is for modules which only function on a dedicated server. As of 1.13 all server classes are present on the client.

The deprecated category is where deprecated modules will be located. The deprecation of a module means the module should be in the deprecated category, regardless of whether the module was previously in common, client or server.

The experimental category is where experimental modules are located per the RFC in #499. A module should only be present in the experimental category if the entire module is experimental. If a module in client, server or common has some parts marked as experimental, the module will stay in client, server or common.

[sfPlayer1]

in-dev fabric API dependency that only contains non-deprecated modules

That’s certainly something I’d like to offer, probably even by default, end users always get full. A complementary legacy-only jar might synergize nicely with IDE access restrictions such that auto-imports pick from non-legacy, but old code still compiles and runs with some warnings. This means 3 distributions: full, normal-only, legacy-only.

[Vaerian]

Kind of unrelated, but also slightly related I think it would be good if in each module readmes there was information relating to the status of the module (stuff relating to what this RFC addresses). Like what if there were some badges under the title of each module that mentioned the version that it is updated to, the status of the module, and which sides it applies to.

As an example

Fabric Lifecycle Events (v1)

This way we could display more meta information about each module for mod developers. This is just a list of some ideas for the labels.

for modules that are for both the client and server or a mix of dedicated client and non-client code for modules that should only ever be used in a client context for modules that should never be used in a client context

for modules that are taking a long time to be updated (cough biomes) for modules that have been superseded by another module for modules that are experimental for modules that are fully updated and working

And then obviously the last version of the game it worked for