MinecraftDev: IntelliJ support for Minecraft modding, across nine loader ecosystems
Plugin for IntelliJ IDEA that gives special support for Minecraft modding projects.
At a glance
- What is it?
- MinecraftDev is an IntelliJ IDEA plugin that adds platform-aware editing for Spigot, Fabric, Forge, NeoForge, Mixins and more. The hard question is not what it does but whether its per-IDE-version release train matches the IDE you actually run.
- Who is it for?
- Adopt MinecraftDev if you write mods or plugins in IntelliJ IDEA and your work spans more than one loader, since the plugin's platform list is the reason to install it. Skip it if you build outside IntelliJ, or if you pin an IDE version the plugin does not yet ship a matching build for.
- Can I use it commercially?
- Yes, with conditions. LGPL-3.0 is a weak copyleft licence: you can use it inside commercial and closed-source software, but if you distribute changes to its own files, you must publish those changes under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Kotlin, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem: Minecraft modding has no single project shape
A Minecraft modding project is not one kind of project. A Spigot plugin, a Fabric mod, a Forge mod and a Velocity proxy plugin use different APIs, different entry-point declarations, different Gradle plugins and different metadata files. The code looks similar enough that a general Java or Kotlin setup gets you part of the way, and different enough that it constantly gets the rest wrong: unresolved symbols in platform classes, no completion for mixin targets, no awareness of the descriptor files that tell the loader what to load. MinecraftDev exists to close that gap inside IntelliJ IDEA. It is aimed at people who already write mods or server plugins and want the IDE to understand the platform they are targeting, rather than treating the project as plain JVM code. The README lists the supported targets explicitly: Spigot (with Paper), Sponge, Architectury, Minecraft Forge, NeoForge, Fabric, Mixins, BungeeCord (with Waterfall), Velocity and Adventure. That list is the product. If your work sits in one of those ecosystems and you edit it in IntelliJ, the plugin's whole reason to exist is making that ecosystem legible to the editor.
What the plugin actually hooks into
The repository is a Kotlin IntelliJ plugin, which means it is built against the IntelliJ Platform SDK and packaged through the Gradle IntelliJ Plugin that the README names. That plugin handles downloading IntelliJ dependencies and packaging the result. The platform list is not just documentation: the README references per-platform icon assets under src/main/resources/assets/icons/platform/, with files such as Spigot.png, Fabric.png, Forge.png, NeoForge.png, Mixins_dark.png and Velocity.png. Those assets are what the IDE shows when it recognises a project as belonging to a given platform. The recognition itself is the mechanism that matters. IntelliJ decides which facets, inspections and completion contributors apply based on the project's build files and structure, and MinecraftDev supplies that logic for each supported loader. The README does not document the internal facet model, the inspection list, or how a project is classified, so anyone who needs those details has to read the source. What the README does establish is the scope: one plugin covering many loaders rather than a separate plugin per ecosystem, which is also why the compatibility surface is large.
Installing it and building it from source
For normal use you do not build anything. The README states the plugin is on the JetBrains plugin repository, so installation goes through IntelliJ's own browser: File -> Settings -> Plugins, then Browse Repositories, search for Minecraft, install, and restart IntelliJ to activate it. Working on the plugin itself is a different path. The README requires JDK 21 available to Gradle, and points at Adoptium for a Temurin build. From there the commands are ./gradlew build, which produces the plugin .zip in build/distributions, and ./gradlew runIde to launch a sandboxed IntelliJ with the plugin loaded. One detail worth reading twice: code is generated during the build, and ./gradlew generate runs that generation without a full build. The README says the task is necessary to work on the code without errors before the initial build, which means a fresh clone will show unresolved references until generation has run at least once. Formatting is handled by ktlint through the ktlint-gradle plugin, with ./gradlew format applying it. For IDE setup the README recommends ./gradlew ktlintApplyToIdea addKtlintFormatGitPreCommitHook, which configures the IDE's style settings and installs a pre-commit hook that formats code automatically.
The release train is tied to IntelliJ versions, and that is the real constraint
IntelliJ plugins are compiled against a specific platform version, and the plugin's release naming reflects that. The three most recent releases are 1.8.22-2026.2, 1.8.22-2026.1 and 1.8.22-2025.3, all published on 2026-08-31. The suffix is the IntelliJ branch, not the plugin's own feature version, and the shared 1.8.22 prefix means the plugin code is the same across those three builds while the target IDE differs. The README's build status table lists nightly builds for the same three branches, 2025.3, 2026.1 and 2026.2, which tells you the project maintains parallel tracks rather than a single artifact. The practical consequence: if you run an IntelliJ version outside that set, you are waiting on a build. This is not a flaw in the project so much as the shape of IntelliJ plugin development, but it is the thing that will actually bite a user. It also explains why the repository is not archived and keeps a steady push cadence: the work is partly keeping up with JetBrains releases, not only adding Minecraft features. Anyone evaluating the plugin should check the release list against their own IDE build before installing.
Where a plain Gradle setup is the better answer
If your project is a single-loader mod with a well-maintained Gradle plugin, the loader's own tooling already generates the metadata, resolves the platform dependency and wires up the run configurations. MinecraftDev adds editor intelligence on top of that, but it does not replace it, and the README frames the Gradle IntelliJ Plugin as the packaging mechanism for the plugin itself, not as a mod build system. So for a one-loader project where the only friction is a missing run task, the fix is in your build.gradle.kts, not in an IDE plugin. The comparison worth making is against the loader-specific Gradle plugins plus whatever the loader's own documentation recommends. Those tools own the build and the run configuration; MinecraftDev owns what the editor knows about the platform. If you never open IntelliJ, or you edit in VS Code or a plain text editor, the plugin is irrelevant regardless of how good its platform coverage is. That is a real boundary, not a hedge. The plugin is an IDE integration, and its value is entirely inside the IDE.
Licence and the cost of keeping up
MinecraftDev is licensed under LGPL-3.0-only, per the README and license.txt. That is a copyleft licence, and it matters more here than for a typical library because the artifact is a plugin that links against the IntelliJ Platform rather than a library you import. If you only install the plugin from the JetBrains repository and use it to write your own mods, the licence covers the plugin, not your mod. If you fork it, redistribute a modified build, or bundle it into something you ship, the LGPL's terms apply to that distribution. This is a description of the licence text, not legal advice; read license.txt and talk to someone qualified if you plan to redistribute. The maintenance cost of the plugin itself is visible in the repository setup: JDK 21 is required, code generation runs as part of the build, ktlint enforces style, and there is a pre-commit hook task to install. Upgrading means tracking three IntelliJ branches at once. For a user, the cost is simply staying on a supported IDE version; for a contributor, it is a build that needs generation before it compiles cleanly.
Who this is for, and what to check first
The plugin is for people who write Minecraft mods or server plugins in IntelliJ IDEA, especially those who work across more than one loader. The platform list in the README is unusually broad, covering client mod loaders, server plugin platforms, proxy software and the Mixins library, and that breadth is the argument for installing it rather than a per-loader alternative. It is not for people who build outside IntelliJ, and it is not a substitute for the loader's Gradle plugin, which still owns dependency resolution and run configurations. Before installing, verify two things: that a release exists for your IntelliJ branch, since the current 1.8.22 line ships 2025.3, 2026.1 and 2026.2 builds and nothing else, and that the platforms you target appear in the README's supported list. If you are building the plugin from source, run ./gradlew generate before expecting the project to resolve, and set up JDK 21 first.
Editorial conclusion
Adopt MinecraftDev if you write mods or plugins in IntelliJ IDEA and your work spans more than one loader, since the plugin's platform list is the reason to install it. Skip it if you build outside IntelliJ, or if you pin an IDE version the plugin does not yet ship a matching build for. Before committing, check that a release exists for your exact IDEA branch (the 1.8.22 line currently ships 2025.3, 2026.1 and 2026.2 builds), and read license.txt to confirm how LGPL-3.0-only interacts with your own distribution plans.
Community notes