• Add https://vineflower.org/ decompiler support.
• Update to Gradle 8.3, and latest version of all dependencies.
• Add support for deprecated modules when using fabricApi.module
• Lazily download decompilers. Also allows changing the decompiler version.
• Two fixes causing outputs to not be reproducible in certain situations.
• Add Fabric-Jar-Type manifest entry, either classes or sources. Can be used by mod distribution platforms to ensure that the correct jar is uploaded.
• Add option to configure known INVOKEDYNAMIC BSMs.
• Suppress the Failed to verify authentication error in the console log.
• Share processed Minecraft jars between sub projects when the processor inputs are the same.

• Rework how the generate sources task applies line mappings, making it more consistent.
• Remaped jar/source output jars are now reproducible by default.
• Don't allow running game/genSources tasks in parallel with each other. (Ever tried to run 10 copies of Minecraft at once :D)
• Ensure jar manifest entries are first when reprocessing zip files.
• Inner class interface injection fixes
• Don't publish none main source sets by default
• Support Kotlin 1.9.0 beta
• Fix idea run configs with spaces in the name
• Eclipse is added to the ANSI supported IDEs
• Improvements to Minecraft metadata downloading, will now handle recently released Minecraft versions better.
• Fix IncludedJarFactory using a shared cache dir, and fix including libraries not producing a reproducible output jar.
• Apply AW's when remapping mods, fixes a few mods not working as expected in dev.
• Fix custom intermediate mapping providers using the same cache key.
• Improve genSources error messages.
• Don't use arg files when running in a none ASCII file path.
• Fix constructor mappings in layered mappings.
• Create RunConfigurationSettings with Gradle's object factory.
• Other smaller fixes and improvements.

This is mostly a small manintaince release to update the depedencies and fix some bugs.

• Updated to Gradle 8.1.
• Rewritten the Minecraft library handling:
  • Upgrades LWJGL when using Java 19 or later.
  • Supports the official Windows arm64 natives added in the 1.20 snapshots.
  • The code is now much easier to maintain and test.
• Rewritten the Kotlin metadata remapping to support the latest metadata library.
• Set roles on Loom's configurations.
• Fix @Environment(EnvType.CLIENT) not being added to the named minecraft client jar when using split sources.
• RunConfigSettings allow specifying the main class name.
• Set a min heap size for the JVM used by the decompiler.

• Generate and attach Minecraft sources when clicking 'Download Sources' in intelij, no 3rd party plugin required.
• New MinecraftJarProcessor API replacing the deprecated JarProcessor API.
• Add new fabric.loom.multiProjectOptimisation property to opt into complex optimistations for certain projects. This simplifies the logic used in simple projects, removing the prepareRemapJarTask. You should only enable this option when all of your sub projects share the same Minecraft and mappings versions.
• Read Fabric-Loom-Remap from a dependencies manifest, this allows it to opt-in/out of remapping, even if it does not have a fabric.mod.json file.
• Jar processor inputs such as interface injection or access wideners are now also read from project dependencies.
• Support MinimalExternalModuleDependency as a FileSpec input. This allows using version catalogs with layered mappings.
• Rework how memory intensive objects are handled, should hopefully reduece memory usage for certain project setups.
• Fix a number of bugs with the mod configuration remapping, it should now have the same behaviour as the default Gradle configurations.
• Large internal changes to prepare for supporting upcoming fabric loader and Gradle features.
• Many smaller bug fixes and changes.

Full changelog / diff:
https://github.com/FabricMC/fabric-loom/compare/dev/1.0...dev/1.1

• Split incoming mod dependencies when using split common/client sourcesets.
• Improvements to error handling/reporting and bad state recovery, reducing the need for clearing caches or --refresh-dependencies.
• Add API to configure mod remapping configurations (clientModImplementation is added when using split sourcesets)
• Improve VSCode launch configurations for multi project builds.
• Use Java argfiles to support long command lines (Lots of dependencies). (Also worksaround a crash with newer AMD drivers)
• Include client only entries manifest entry in sources jar.
• Add stable APIs for use by the "MinecraftDev" intelij plugin.
• Add DSL for the Mixin annotation processor message levels.
• Support setting environment variables in run configurations.
• Use TinyRemapper's Ref counting FileSystemHandler.
• Rewrite download handling to be more resilient and maintainable.
• Add (opt-in) ValidateMixinNames task to validate mixin class names match their target.
• A wide range of smaller bug fixes and performance improvements.

This update is focused around finalising the split sourceset feature and improving the reliability of loom overall. Loom will now attempt to recover from a previously failed or canceled build. The move to version 1.0 will allow us to better denote any breaking API changes to future loom versions.

Split common/client code

Loom 1.0 provides a full suite of tools to build a mod with split common/client code. The previous loom version introduced compile time safety when compiling against Minecraft code. Loom 1.0 expands this to incoming mod dependencies such as Fabric API. Any mod dependency that was also built with this will be split and applied to the correct sourceset, this ensures that you cannot depend on a client only API from your common code.

Please see the updated Loom wiki page with details on how to enable this for your project. https://fabricmc.net/wiki/documentation:fabric_loom

To update please set your loom version to 1.0-SNAPSHOT at the top of your build.gradle file.

• Support Minecraft 1.19
• Add opt-in option to split client code into its own source set (experimental)
• Add DSL for mod classpath groups (experimental)
• Major improvements and fixes to Kotlin metadata remapping
• Support all older versions of Minecraft (1.13.2 -> a1.2.5 tested)
  • Fabric does not offer mappings or APIs for these versions, you will need to supply your own.
• Dependent mods can provide addional javadoc comments
• Many bug fixes and smaller improvements

See full list of changes here

Split Sourcesets

For years a common source of server crashes has been from mods accidentally calling client only code when installed on a server. Starting with Loom 0.12 and Loader 0.14 an experimental option has been added to require all client code to be moved into its own sourceset. This is done to provide a compile-time guarantee against calling client only Minecraft code on the server. A single jar file that works on both the client and server is built from the two sourcesets.

The following snippet from a build.gradle file shows how you can enable this for your mod. As your mod will now be split across two sourcesets, you will need to use the new DSL to define your mods sourcesets. This enables Fabric Loader to group your mods classpath together. This DSL is also useful for some other complex multi-project setups.

loom {
   splitEnvironmentSourceSets()

    mods {
        modid {
            sourceSet sourceSets.main
            sourceSet sourceSets.client
        }
    }
 }

This feature has been in development for almost 6 months, requiring major changes to Loom and Loader. Due to the fundamental changes issues are expected, so if you do find an issue please make sure to report it.

Even though this is still an experimental feature Fabric API already makes use of this in the 1.19 branch. There are still some improvements and related features that are planned for future loom versions, that will allow modders to get the most out of this. Meanwhile for more advanced modders that like trying out new things it should be in a good enough state to use.

Loom 0.11

• Interface Injection
  • Provides a simple way for mods to add an interface to Minecraft classes.
  • Mixin should be used to implement the interface on the class at runtime.
  • Comments are added to the decompiled source noting the mod id for the injected interface.
• Add server only option for mods that only target the server.
  • Compile-time safety to prevent accidental usage of client only classes.
  • Improved performance as there is less to download, process and decompile.
• Full support for computers using the ARM processor architecture.
  • Supports MacOS (Apple silicon), Windows and Linux
  • Updates LWJGL to 3.3.0 and uses the official ARM natives.
  • Automatically includes a small mod to fix a MacOS only issue for older Minecraft versions.
• Kotlin class metadata remapping.
  • Fixes issues with kotlinx.serialization and issues when depending on kotlin libraries.
• Exclude client only Minecraft libraries from server run configurations in Inteliij or Gradle.
• Add an option to remove log4j from the compile classpath.
  • Mods should move over to using SLF4j
• Highly experimental support for splitting the minecraft jar into common and client only jar files.
  • Currently unsupported by fabric-loader, future loom versions will build upon this.
• Improvements to the decompiler API.
  • Additional functionality exposed for 3rd party decompilers.
  • Register default decompilers earlier so they can be configured without using afterEvaluate.
  • Better support for multiple decompile tasks.
• Update to Java 17 and Gradle 7.3
• Continued work on performance improvements
  • Project configuration time has been reduced by moving some launch requirements such as extracting natives and writing dli/log4j configuration files to pre launch tasks.
  • Remap jar and sources tasks have been rewritten to run asynchronously when Parallel execution is enabled.
  • More resources are now shared between multi-project setups, reducing memory consumption. Even when the shared caches option is not possible.
• A number of other misc bug fixes and smaller improvements.

Interface Injection

Interface injection is a compile time only feature, this means that a Mixin should also be used to implement the interface onto the target class. The following snippet can be added to your fabric.mod.json file to add an interface to the net/minecraft/block/Block class.

{
  "custom": {
    "loom:injected_interfaces": {
      "net/minecraft/class_2248": ["net/fabricmc/example/ExampleInterface"]
    }
  }
}

New Options

loom {
    // Disables client related features and resources.
    serverOnlyMinecraftJar()
    // Enable runtime only log4j, forces mods to use SLF4J for logging.
    runtimeOnlyLog4j = true
}

Loom 0.11 contains major rewrites to a number of core functions to make a lot of these new features possible, if you find any issues please make sure to report them.

Changelog

• Minecraft 1.18 support (modmuss50)
  • Register the new LVT naming pattern with tiny remapper
  • Rebuild record components as they are stripped by proguard
  • Fix record signatures as they are also stripped by proguard - See: https://bugs.mojang.com/browse/MC-236947
  • Support new bundled server jar
• Fixes to java software component (Juuxel) - more on this at the end
  • Add namedElements configuration containg the named jar, helps with multiproject builds (modmuss50)
• Transitive access widener support. Required Loader 0.12 (shartte)
  • Comments are added into the decompiled source saying what mod is providing the transitive changes. (modmuss50)
• Make CFR the default decompiler (modmuss50)
  • Debugging Minecraft code should work better now
  • The decopiler output should be superior to Fernflower
  • Fernflower can still be used by running genSourcesWithFernflower
  • Rewritten decompile tasks to cleanup and fix a number of issues.
• Add modCompileOnlyApi, modRuntimeOnly; deprecate modRuntime (Juuxel)
• Disable ANSI logging (colours in console) when gradle's --console plain arg is used (modmuss50)
• Add loom.modVersion to read the version specified the fabric.mod.json file (modmuss50)
• Expose layered mappings as an experimental API (modmuss50)
• Migrate loom fully to the mapping-io library (modmuss50)
  • Port lorenz-tiny to mapping-io (modmuss50)
• Make the run configs run dir relative to the project and not the root project (modmuss50)
• Forward standard-in to the runServer task, fixes not being able to interact with the server via the console. (modmuss50)
• Access Wideners are now valided to ensure that all the entries are valid. (modmuss50)
• Fix signed mods not having their signature removed after being remapped. (modmuss50)
• Improve run config argument handling, fixes issues with arguments that contain spaces (modmuss50)
• Use NIO for zip related tasks. (shedaniel)
• Add localRuntime and modLocalRuntime configurations (Juuxel)
• Add an experimental option (disabled by default) to use tiny-remapper to remap Mixins instead of using Mixin's annotation processor. (LogicFan)
• Refactor intergration tests, also run tests against Java 17 (modmuss50)
• General code cleanup, peformance improvements and modernisation (modmuss50, NinjaPhenix, Juuxel, shedaniel)

Deprecations

The old way of defining maven artifacts to publish has been deprecated in favor of using the java component. This means that this old form:

mavenJava(MavenPublication) {
    // add all the jars that should be included when publishing to maven
    artifact(remapJar) {
        builtBy remapJar
    }
    artifact(sourcesJar) {
        builtBy remapSourcesJar
    }
}

Should now be written as:

mavenJava(MavenPublication) {
    from components.java
}

This changes now follows the gradle documentation, the old method will continue to work with loom 0.10 but a deprecation warning will be shown. In the rare/complex case where the old method is required loom.disableDeprecatedPomGeneration(publishing.publications.mavenJava) can be used to supress the deprecation warning, this should only be used if required!

See https://github.com/FabricMC/fabric-example-mod/pull/141/commits/671b3d4526df8ef3ae1a7cd30c4af8c12a35bbb6 as an example of how the example mod was updated.

Breaking changes

Due to the above changes some multi-project builds may have broken. Now when you depend on a loom subproject you must specify the namedElements configuration. This ensures that you are depending on the named "dev" jars, and not the intermediary remapped "production" jars. See as follows:

implementation project(path: ":mySubProject", configuration: "namedElements")

If you are using kotlin for your build script it will be as follows:

implementation(project(":mySubProject", configuration = "namedElements"))

If you need any help with loom 0.10 please don't hesitate to ask in the #mod-dev-gradle-ides channel on Discord.