Make mixin entries from the mods.toml optional.

[marchermans]

This allows modders to specify that a mixin config is optional.
It will not be loaded if it does not exist.

Usecase:

• Compatibility mixins loaded from a seperate sourceset, for example when creating compatibility layers with shader mods.

[neoforged-pr-publishing]

• Publish PR to GitHub Packages

Last commit published: 3be393341f68b35436955dfafdcd0db8c056da61.

PR Publishing

The artifacts published by this PR:

• 📦 net.neoforged.fancymodloader:tests:6.0.13-pr-237-feature-optional-mixins
• 📦 net.neoforged.fancymodloader:junit-fml:6.0.13-pr-237-feature-optional-mixins
• 📦 net.neoforged.fancymodloader:earlydisplay:6.0.13-pr-237-feature-optional-mixins
• 📦 net.neoforged.fancymodloader:loader:6.0.13-pr-237-feature-optional-mixins

Repository Declaration

In order to use the artifacts published by the PR, add the following repository to your buildscript:

repositories {
    maven {
        name 'Maven for PR #237' // https://github.com/neoforged/FancyModLoader/pull/237
        url 'https://prmaven.neoforged.net/FancyModLoader/pr237'
        content {
            includeModule('net.neoforged.fancymodloader', 'tests')
            includeModule('net.neoforged.fancymodloader', 'junit-fml')
            includeModule('net.neoforged.fancymodloader', 'earlydisplay')
            includeModule('net.neoforged.fancymodloader', 'loader')
        }
    }
}

[embeddedt]

Interesting, but what is the advantage over the current convention of overriding shouldApplyMixin in a mixin plugin (which is also more flexible)?

[marchermans]

Interesting, but what is the advantage over the current convention of overriding shouldApplyMixin in a mixin plugin (which is also more flexible)?

Mixin crashes before that if the json is not found in the jar.
So when I am running in none shader compat mode, it just hard crashes as the mixin json it self lives in the other sourceset with the compat code.

[FiniteReality]

Suggestion: PotentialMixinConfig since it's a mixin config we're specifying, not an individual mixin

[marchermans]

Right, let me fix that.

[Technici4n]

That's really weird because it is a dev-only feature. I wonder if adding mixin configs that depend on some mods being loaded would not be a more general solution. 🤔

[marchermans]

That's really weird because it is a dev-only feature. I wonder if adding mixin configs that depend on some mods being loaded would not be a more general solution. 🤔

Maybe, but this is a good first step, and when the need arises we can definitely iterate on this design and expand the conditions.

[Technici4n]

It's weird to ever have this in a production environment. And in dev there should be a suitable way to trim the unwanted mixin entries, no? (E.g. Gradle magic)

We should also think about why this isn't done with accesstransformers.

[marchermans]

It's weird to ever have this in a production environment. And in dev there should be a suitable way to trim the unwanted mixin entries, no? (E.g. Gradle magic)

We should also think about why this isn't done with accesstransformers.

It is possible to do with a lot of gradle magic, where gradle edits the file, and injects stuff into it, all in all, with running with IDEA support in the back of my mind (as that is now the default way of running my mods), it is a lot of work, for something I think we should start working towards (aka optional, conditional on mods, etc). This PR provides initial infrastructure to do that (with the capturing record, and filtering logic) to eventually get to full conditional support for this. But we can iterate and see what the community wants or needs.

[neoforged-releases]

🚀 This PR has been released as FancyModLoader version 6.0.6.