Feature Parity with MixinBooter and related mixin products

[Rongmario]

Summary

Allow the mixin ecosystem to stabilise by keeping Cleanroom's mixin products equal

Goals

• Allow upstream MixinBooter to pretty much be exact compared to Cleanroom's MixinBooter implementation
• Encapsulate other mixin related addons, primers
• Bring clarity to mixin features so one version does not differ from the other
• Negotiate any merges from upstream Mixin and related products (e.g. MixinExtras)

Non Goals

• Rewrite Mixin
• Develop further on mixin products

Motivation

Currently to "mock" latest MixinBooter, users have to change MixinBooter versioning manually in the config. Extremely unintuitive.

MixinBooter and the backing mixin repository have become a little messy as well, this is a good chance to clean and level the implementations.

SpongeForge is also running into issues because of phases

Description

1. Create only one Mixin fork for Cleanroom and 1.12.2 (repository link: CleanMix)
2. Remove CLEANROOM_DISABLE_MIXIN_CONFIGS field that MixinBooter added in the org.spongepowered.asm.launch.GlobalProperties class
3. Allow DEFAULT environment to tackle mods too
4. Add a way to intercept mixin configs from being added
5. Provide API for finding mixin configs based on "owners" a.k.a mods (search via mod id)
6. Encapsulate other mixin loaders to allow Cleanroom and MixinBooter users to simply rely on our loaders for all mixin mods
7. Allow crash reports to show mixin "stacktrace" (mixin configurations that may have affected the classes mentioned in the stacktrace)
8. To include FermiumBooter's logic for mods relying on it, for Cleanroom can quality control it and to deprecate when necessary.

Dependencies

• Mixin 0.8.7
• MixinExtras 0.5.0

References

No response

Guidelines

• I have and will continue to adhere to the guidelines

[hohserg1]

How about to use HookLib as prefered coremodding frameform?
This will remove many of your suffering with Mixin and reach goals.
HookLib less complicated at usage and internal structure compared to Mixin, so it will be more friendly to users and devs.
4. A hooks are applying to an any class which pass through transformers and after an any transformer, so no need to phases
8. HookLib adding calls of your method instead of copying method to target class, so stacktraces already have clear way to reasoning mod
Also, Desoroxxx said its cool

[kappa-maintainer]

We can't just migrate all mixin codes in 1.12 to another library
In fact, all features listed have been implemented, but in different forks
The only problem is one of these forks did a soft reset and wiped out tons of commit info, we will have to manually diff on it

[hohserg1]

Prob we can.
1.12 have only ~400 open source mods with mixins:
https://gist.github.com/hohserg1/2e34fa7974a04a5eaf312fe1133c1737 (taken from curseforge)
Popular mods may be migrated by us, I saw some mods already was forked to continue support. I can be volunteer.
Also, its not really need to kick out mixins, it can stay as external library and all mods which uses Mixin may continue work as is.
Its issue of better future of 1.12.2 modding, so its good stage to choose something better than Mixin.
As I understand, Cleanroom intend to replace original Forge as prefered platform of 1.12.2 modding. As example, here already some breaking changes like event system.

[KorewaLidesu]

This proposal is focusing on Mixin implementation, so lets keep this outside as a separate proposal rather than try fit it into the current proposal goal. 😉

[Irgendwer01]

Why is there a need to replace Mixins though?

[hohserg1]

bc Mixins have problems and HookLib trying to solve them:

1. stacktraces
2. phases
3. complicated api (this point not a issue of this proposal, but anyway)

[Rongmario]

If you can come up with plausible reasoning & plan, feel free to submit a proposal for using HookLib, but bear in mind we need to be able to remain compatible with mods that use mixins with little to no extra effort.

[Rongmario]

Included plans to merge FermiumBooter's logic for mods depended on it, it will never be official API however.

[Ecdcaeb]

FermiumBooter and GTNH both seem to provide solutions for using Config to control Mixin. I think Cleanroom also needs it, rather than just manually combining ConfigAnytime in MixinPlugin.

[Rongmario]

The inclusion of it has happened, for Cleanroom, this portion will be included in Fugue. The maven artifacts of MixinBooter will also not include this portion as it is not API but mere compatibility for those that use fermium.