Properly fix #2057 by asking tiny remapper to patch package access

[liach]

Needs a loom pr as well. The loom pr can properly fix the problem
in dev env.

Signed-off-by: liach liach@users.noreply.github.com

[liach]

@Chocohead Thank you for your suggestion from #2057 (comment)

[modmuss50]

No, this shouldn’t be used in loom as it will change it for mods compiling. I wouldn’t change it here either as there is no need to it will just cause added confusion between the two envs

[liach]

then should yarn output like an access widener alongside mappings indicating members that need widening? or what approach do you suggest?

[modmuss50]

I suggest we dont touch it. Mod dev envs should not have mapping specific access wideners as we would need to bake them into each mod.

Even we if fix all of the package access issues it will need to stay as it will break when an update comes along and adds a new class.

[liach]

I suggest we dont touch it. Mod dev envs should not have mapping specific access wideners as we would need to bake them into each mod.

Even we if fix all of the package access issues it will need to stay as it will break when an update comes along and adds a new class.

so you suggest keeping the status quo, which i agree. and we leave the handling to loader exclusively?

[modmuss50]

Yes.

I think mixin does complain a little in the log. I wouldn’t be against removing that log line though.

[liach]

Hmm, should we add to tiny v2 metadata that some namespaces needs package access checks?
I mean, we can add extra metadata like \tpackage-access-checks\tfalse\ttrue etc. the values are tab split and each value indicates if each namespace may have package access issues

[liach]

Closing in favor of FabricMC/tiny-remapper#46