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.

This segment will likely be removed from this page once it is ensured the information contained within it is detailed upon on more specialized pages.

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 directly copied, and you should prioritize 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 prioritized when there is no obvious Wiki answer. This being kept in mind, the following are loose, general advice for using Mixin in your project.

• When needing to reference an instance of the target class in your Mixin and pass it to a method call or constructor, you cannot use this directly, as your Mixin class is not yet of the type of the target class. Instead, you must first cast to Object and then to the target class: (TargetClass) (Object) this. This should not be used as a way to access the target class's fields or methods, as those can be accessed through @Shadow.
• @Redirect and @ModifyConstant mixins cannot chain(be applied more than once on the same target at the same time). Alongside @Overwrite, which is incredibly incompatible as it replaces the method outright, please avoid them if possible and prioritize 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. Mainly, @WrapOperation and @ModifyExpressionValue can be used instead of @Redirect and @ModifyConstant for all cases which do not involve intentionally clashing with another mod. @Overwrite should almost never be used over more precise modifications using injectors. See the official MixinExtras wiki for more details on the library's features.

• If you're adding custom fields or methods to a target class, prefix them with your modid and a separator such as $ or _ and annotate them with @Unique. Such that addedField is instead named mymodid$addedField. This is to avoid conflicts between mods adding a field or method named the same way. This applies both to fields you add to the Mixin class, and to accessor methods which are not static.

To learn more on Mixins and how to use them, refer to the introduction page, 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.