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.

Done in #2171.

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

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.

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

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

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.

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)

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

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

@sfPlayer1 Mind evaluate this?

I personally oppose this. I don't think splitting the directory structure so would bring much advantage. For modders, they should not select dependencies based on client/server but should based on the features they need (or just all api parts wholesale if they are lazy). The lifecycle indication makes much more sense from a dependency viewpoint, which is already done in #1253. However, rearranging directories based on that is an overkill, considering the costs it impose onto pull requests, etc. On the users' side, they would only choose these libraries as prescribed by mod authors or as managed by package managers; these information are relatively useless to them.

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.

I'm currently strongly leaning towards not separating client/server, but only by lifecycle (root=normal, deprecated/legacy, experimental). Whether experimental should be separate or besides the normal ones is TBD, IMO not - so essentially just moving deprecated into a sub dir.

Putting them into an experimental folder would be nice if we let certain modules, such as transfer api, just get shipped with FAPI once APIs are in between "Getting final reviews" and "About to merge." IMO the emphasis is less on getting the API out and more on improving the reviewing process.

Maybe not even splitting the directories, but it has crossed my mind that we could have an in-dev fabric API dependency that only contains non-deprecated modules. Possibly that is not too hard to add into the buildscript?

My main concern about splitting directories is that it adds extra costs to existing pull requests when a module migration/promotion happens.

For leaving the deprecated modules out of api, it should probably be possible with gradle, given gradle always split dependencies as compile and runtime variants; we can make root api implementation the deprecated modules and api the regular modules.

I was thinking about inspecting the fabric.mod.json.

Q: if we do this, will we be doing it in 1.17 or at the start of 1.18 snapshots?

Moving the folders can happen at any time, especially doing only the legacy ones shouldn't break anything including PRs.

moving only the legacy ones sound like a good approach.