Here's a collection of assorted Fabric-related modding tips gleaned from experiences on advising users of the API.

• Due to the injection-based approach of Fabric's API development, we don't tend to patch classes outright in a way visible to the end user. As such, you may occasionally find Fabric extensions of vanilla classes when you run into something you cannot do. For example:
  • Block.Settings → FabricBlockSettings (except 1.20.5)
  • EntityType.Builder → FabricEntityTypeBuilder
• For a built-in resource pack or data pack, please ensure that an “assets/[mod id]” or “data/[mod id]” directory path is present, respectively! IDEA users might find themselves accidentally creating an “assets.[mod id]” directory - this won't work.

It should be kept in mind whenever learning about Mixin in any capacity that any example is limited to its own situation. No example should be copied, and you should privilege using examples as ways to better understand syntax and general principles, rather than a tutorial to achieve your specific goal. Every Mixin you make should be tailored to its isolated use-case.
Refer to relevant wikis and Discord help channels mentioned further in this section when you are in doubt or encounter an issue, getting direct help and asking questions is a natural and expected part of learning Mixins and should be privileged when there is no obvious Wiki answer. This being kept in mind, the following are loose, general advice for using Mixin in your project.

• To cast a class to an interface it doesn't implement, or cast a final class, or cast the mixin to your target class, you can use the “(TargetClass) (Object) sourceClassObject” trick.
• @Redirect and @ModifyConstant mixins cannot currently be nested (applied by more than one mod in the same area at the same time). This might change later in development - however, for now, alongside @Overwrite, please avoid them if possible and privilege using options provided by MixinExtras:
  • MixinExtras, a library for Mixin bundled with Fabric, provides alternatives to the aforementioned options that can chain when used in the same place as another Mixin, and should be privileged by default. Namely, @WrapOperation and @ModifyExpressionValue can be used rather than @Redirect and @ModifyConstant for most applications, and @Overwrite should almost never be used over @WrapMethod. The less compatible annotations may still be preferable if you specifically wish for the game to crash if another mod tries to replace the same target with a non-chaining Mixin, but otherwise should not be used. To understand basic usage of MixinExtras tools see the MixinExtras wiki.

• If you're adding non-private custom fields or methods to a target class, prefix them with “[modid]$” or another unique string and annotate them with @Unique. Essentially, “mymod$secretValue” instead of “secretValue”. This is to avoid conflicts between mods adding a field or method named the same way.
• To learn more on Mixins and how to use them, refer to Introduction to Mixins, the official Mixin Wiki, the MixinExtras Wiki and most importantly frequently ask questions in the Fabric Discord's dedicated #mod-dev-mixin channel, or the SpongePowered Discord's #mixin channel.

• Packets always begin execution on the network thread, however accesses to most Minecraft things are not thread-safe. In general, if you're not exactly sure what you're doing, you want to parse the packet on the network thread (read all the values out), then use the task queue to perform additional operations on the main server/client thread.

• Avoid using the java.awt or javax.swing package and their subpackages. AWT does not work well on all systems. Several users have reported that it hangs Minecraft.