0.2.0-alpha.4+1.21.1
Compatibility
Required content
Changes
🧰 DevKit API 0.2.0-alpha.4
A maintenance and tooling release: registry lookup, targeted config synchronization, runtime diagnostics, and cross-version tag generation.
DevKit API is a lightweight library for Fabric mod developers. It provides reusable tools for registries, networking, Data Components, synchronized configuration, and data generation, without adding gameplay content of its own.
✨ Highlights
Registry Lookup
Declared entries can be resolved again by path, which helps when registration and use live in different classes:
KRegister.get(path)returnsOptional<RegistrySupplier<T>>, empty for unknown paths;KRegister.contains(path)reports whether a path was declared;KRegister.size()reports how many entries a container holds;- all three work before
bootstrap()runs, and the supplier stays unbound until it completes.
Targeted Config Synchronization
Configuration synchronization is no longer limited to a full broadcast:
ConfigSyncManager.sendTo(player, configId)pushes one configuration to a single player;- non-authoritative configurations are refused, matching the client-side check that already rejected them on arrival;
ConfigManager.delete(modId, name)removes a configuration file and reports whether one was removed;- applying a synced config on the client is logged at info level with the number of fields written, so synchronization is observable without a debugger.
Runtime Diagnostics
The all-in-one artifact registers one read-only status command, /devkit info. It reports the installed DevKit version, networking capabilities, the number of registered packets, how many declared registry entries are bound, and the number of synchronized configs.
DevkitCore.getApiVersion() and DevkitCore.getModVersion() expose the same information programmatically, which is useful for crash reports and support requests.
Tag Generation Across Versions
The vanilla tag provider API changed twice between 1.21.1 and 1.21.11. TagHelper now hides both renames behind a single hook:
- override
buildTags()instead of the version-specific provider hook; add(key, entries...)andaddOptional(key, entries...)write identifiers directly, with no need to resolve a registry key first;tag(path)andcTag(path)build namespaced and convention tag keys;- overriding the provider hook directly still works, so existing code keeps compiling.
One provider source file now compiles unchanged on 1.21.1, 1.21.8 and 1.21.11.
🔧 Fixes
- Config sync initialization: the synchronization payload and the player join listener are initialized on demand. Server-authoritative configs reach clients even when the sync manager is never initialized explicitly. Previously a config could be registered and then silently never sent.
- Config path validation: segments that start with a dot are rejected instead of resolving outside
config/<modId>. - Client initialization failures: reported as errors, so a missing client packet receiver is no longer hidden behind a debug message.
- devkit-core dependencies: the module declares its Fabric API dependency. Installing a module without Fabric API now fails with a dependency error instead of a class loading failure during startup.
- ModelGen.simpleItem: logs a warning instead of silently skipping identifiers that are not registered.
- Config sync logging: the manager no longer logs a misleading zero config count on startup.
📦 For Developers
Dependent mods can consume DevKit API through Modrinth Maven:
repositories {
maven { url = "https://api.modrinth.com/maven/" }
}
dependencies {
modImplementation "maven.modrinth:devkitapi:0.2.0-alpha.4+1.21.1"
}
Maven Local publishing remains available as a fallback. See the README for full setup instructions.
Alpha software. Public API signatures may still change before 1.0.
Projects on Modrinth are automatically available through a Maven repository for use with JVM build tools such as Gradle. To learn more about the Modrinth Maven API, click here.
Note: When available, you should use the creator's maven repo instead as it will have transitive dependency information that the Modrinth Maven API does not. You may also end up with duplicate dependencies if you use a mix of Modrinth and non-Modrinth Maven repositories for your dependencies, because the group identifier will be different when served through the Modrinth Maven API.
Maven coordinates:
Version ID:
build.gradle:
repositories {
exclusiveContent {
forRepository {
maven {
name = "Modrinth"
url = "https://api.modrinth.com/maven"
}
}
// forRepositories(fg.repository) // Uncomment when using ForgeGradle
filter {
includeGroup "maven.modrinth"
}
}
}
// Standard Gradle dependency
dependencies {
implementation "maven.modrinth:1Fq0uOtL:VuKkixuS"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:1Fq0uOtL:VuKkixuS"
}

