Fabric: [RFC] Reorganize location of modules in repository structure

[i509VCB]

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.

[XakepSDK]

What about server only modules? E.g. modules that won't prevent vanilla client to work with a modded server

[i509VCB]

Modules that target the logical server would be part of common. This is because the "server" exists on both a client (as an integrated server) and dedicated server.

If a module only works on the dedicated server, it would be part of common also since Mojang no longer has any dedicated server only classes.

If this does change in the future, we will revisit a specific dedicated server category.

[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

[Vaerian]

As for the folders, I think there might be problems when it comes to things like experimental client modules. Like which folder would that go in? It might be a better idea to have one layer of folders for client/common and then inside of those folders another layer for deprecated/experimental

[i509VCB]

The sticker stuff is very interesting, but arguably out of scope of this issue. Make another issue for it probably.

My rationale behind experimental taking precedence over client or common is that a module would only be temporarily experimental, either being removed or graduated to active in the future.

[OroArmor]

I like this because Minecraft has a lot of features that are hardcoded, and adding another section unhardcoded or put them under the common module.

I think that splitting this up also narrows down what people need to look for. I.e. I want to clean up my rendering, so I check the client modules.

I do wonder about how hard this is to implement and what it would break (ie the old version)

[i509VCB]

We could consider further sub splits in the future for specific types of modules, but for now that is not in scope of this issue

[i509VCB]

Per discussion on discord server is now a category if needed.