feat: Add disableAliases option

[Unnvaldr]

Resolves #1571

[Unnvaldr]

First post content was changed due to wrong issue linked

PS

Also workflow failed because of socket timeout

[Gerrit0]

Looks good!

[Unnvaldr]

@Gerrit0 I came back to this after a while and I've noticed strange extendedTypes behaviour.
While extended types reflections are properly resolved for a class (in my case alt-client.WorldObject), in alt-server.WorldObject they point still on first occurence in whole project (alt-client.WorldObject).
I tried to find where's the problem hiding, but so far I couldn't find logic behind assigning reflection ids to types created from classes heritageClauses.

edit: You can test it in this repo https://github.com/altmp/altv-types/tree/shared-pkg

[Gerrit0]

Yeah, that doesn't surprise me. References are created with types having all their links resolved, so you'll end up with multiple reflections with the same symbol. The ImplementsPlugin relies on getting the symbol to perform inheritance analysis, and that hasn't been updated to support Symbol -> Reflection[] (which really needs to happen due to declaration merging anyways, but I haven't figured out a clean way to do it, and it doesn't break too many people)

[Unnvaldr]

Yeah, that doesn't surprise me. References are created with types having all their links resolved, so you'll end up with multiple reflections with the same symbol. The ImplementsPlugin relies on getting the symbol to perform inheritance analysis, and that hasn't been updated to support Symbol -> Reflection[] (which really needs to happen due to declaration merging anyways, but I haven't figured out a clean way to do it, and it doesn't break too many people)

Is there an issue created for this? If not, would be nice to have one.

[Unnvaldr]

Also on closer look, it seems that every reference from "shared" module is pointing to incorrect symbol in 2nd module, so it's even more vast that I originally assumed.

[Gerrit0]

I don't think there's a canonical issue for it, there's probably some discussion in the 0.20 tracking thread, but I honestly don't remember... and yep, I kind of expected that for the latter as well.

Come to think of it, --packages might be a perfect fit for your repo since it will make TD create two programs and therefore the types will be completely separate... though whether that's a limitation of TD or a feature is kind of undefined right now.

[Unnvaldr]

In such case I think that we need to either properly document what happens if disableAliases is used or just entirely remove it.

[Gerrit0]

Since it hasn't been published in a non-beta version (happy accident), I'm fine with just removing it - it does reveal more obviously problems with the architecture