Module Naming

We currently plan on moving forward with a new naming scheme for Fabric API modules which will finally bring consistency to the module names that up until this point have been mostly a free-for-all. The current naming scheme of fabric-xxx is confusing for 2 main reasons:

• FabricMC has other projects such as fabric-loader and fabric-loom which are not Fabric API modules, yet follow identical name format to API modules
• A module with the name fabric-biome-api is much clearer of a name and more representative of what it does than fabric-biomes. As Player put it:

  fabric-biomes adds 5 new lil' tater biomes

Modules that do not contain API (API in data form is still considered API, such as tags) will not have an -api suffix, such as fabric-resource-loader-v1 and fabric-indigo-renderer

Event-based and registry-based modules will use the -events and -registries suffixes, respectively. These are API, however the -api suffix is redundant because events and registries are inherently API.

Modules names will always be written in plain, grammatical, U.S. English. In English, adjectives come before nouns so that is why modules that are currently named such as fabric-renderer-indigo or fabric-events-lifecycle-v0 would be named fabric-indigo-renderer and fabric-lifecycle-events respectively under the new naming scheme.

Every name consisting of multiple words will have a hypen (-) between the words. This includes class names such as BlockEntity being represented as block-entity.

Module names are intended to be easy to type and remember. Grouping based on type of module (for example, event-based modules) can be part of a wiki article, instead of with a prefix in the naming scheme.

Modules should use -api instead of other words that essentially mean the same thing, unless they are especially significant (such as -events or -registries). For example, in fabric-tag-extensions-v0, the -extensions is fundamentally the same as -api, so it would be replaced with fabric-tag-api-v1

Package Structure

Package structure will not change as much, and if anything just unify to the existing standards. Packages must follow the following format (using fabric-biome-api-v1 as an example):

• API Packages use the root net.fabricmc.fabric.api.biome.v1
• Implementation Packages use the root net.fabricmc.fabric.impl.biome
• Mixin Packages use the root net.fabricmc.fabric.mixin.biome

Note that all package names are singular and follow standard java conventions for package names

Multi-word names will be split or combined depending on what makes sense from a hierarchical standpoint:

• A module named fabric-lifecycle-events-v1 would have the root package net.fabricmc.fabric.api.event.lifecycle.v1 to maintain the hierarchy of lifecycle being a type of event
• A module named fabric-networking-block-entity-v1 would have the root package net.fabricmc.fabric.api.networking.blockentity, because "Block Entity" is a singular construct under "networking", and should not imply that entity was hierarchically inferior to block

The following PRs have been updated to use the new naming scheme:

• #460
• #537
• #539
• #558
• #568

Current modules in the new scheme

Here is how the new scheme would apply to every existing Fabric API module (this is just to demonstrate how the name scheme works for reference, modules will not be mass-renamed):

• fabric-api-base -> fabric-base-api-v0
• fabric-biomes-v1 -> fabric-biome-api-v1
• fabric-blockrenderlayer-v1 -> fabric-block-render-layer-api-v1
• fabric-commands-v0 -> fabric-command-api-v0
• fabric-containers-v0 -> fabric-container-api-v0
• fabric-content-registries-v0 -> fabric-content-registries-v0 (No change)
• fabric-crash-report-info-v1 -> fabric-crash-report-info-v1 (No change)
• fabric-dimensions-v1 -> fabric-dimension-api-v1
• fabric-events-interaction-v0 -> fabric-interaction-events-v0
• fabric-events-lifecycle-v0 -> fabric-lifecycle-events-v0
• fabric-item-groups-v0 -> fabric-item-group-api-v0
• fabric-keybindings-v0 -> fabric-key-binding-api-v0
• fabric-loot-tables-v1 -> fabric-loot-table-api-v0
• fabric-mining-levels-v0 -> fabric-mining-level-api-v0
• fabric-models-v0 -> fabric-model-api-v0
• fabric-networking-blockentity-v0 -> fabric-block-entity-networking-api-v0
• fabric-networking-v0 -> fabric-networking-api-v0
• fabric-object-builders-v0 -> fabric-object-builder-api-v0
• fabric-particles-v1 -> fabric-particle-api-v0
• fabric-registry-sync-v0 -> fabric-registry-api-v0
• fabric-renderer-api-v1 -> fabric-renderer-api-v1 (No change)
• fabric-renderer-indigo -> fabric-indigo-renderer
• fabric-renderer-registries-v1 -> fabric-renderer-registries-v1
• fabric-rendering-data-attachment-v1 -> fabric-data-attached-rendering-api-v1
• fabric-rendering-fluids-v1 -> fabric-fluid-rendering-api-v1
• fabric-rendering-v0 -> fabric-rendering-api-v0
• fabric-rendering-v1 -> fabric-rendering-api-v1
• fabric-resource-loader-v0 -> fabric-resource-loader-v0 (No change)
• fabric-tag-extensions-v0 -> fabric-tag-api-v0
• fabric-textures-v0 -> fabric-texture-api-v0

👍

Notes:
In your example, resource loader actually exposes some api, mainly ordered resource reloading application and mod info access for mod resource packs.

Also I don't think registry sync exposes any api. As of now the list of registry it syncs and requires is hardcoded to all registries.

Imo object-builder-api can just be object-api.

For event and registry, as long as the packages are singular I am fine.

Registry sync does add some very common API such as the registry callbacks, but hmm I didn't realize resource loader also did this. Not sure what we should do about that.

fabric-content-registries-v0 is an API, isn't it?

See this paragraph

Event-based and registry-based modules will use the -events and -registries suffixes, respectively. These are API, however the -api suffix is redundant because events and registries are inherently API.

Basically, if a name of a specific type of API applies such as events or registries, then it is used. This would only be for modules that entirely revolve around events or registries, though, simply containing one does not make it an event or registry module. Future API types will be assessed on a case-by-case basis.

Closing with no objections, new modules or new module versions will have to follow this scheme now.