I am not sure if it is the same underlying issue but supporting type aliases is more important. They allow us to deprecate APIs which we use quite extensively. I am not a fan of renaming imports myself so if you have to pick which one to implement first, I'd vote for type aliases :)
Originally posted by @thomaseizinger in #2647 (comment)
If an earlier version had a type (struct, enum, etc.) by some name, and the new version moves that type elsewhere but leaves a type alias in its place, that is not a breaking change. Currently, this scenario isn't detected, and we should update our simulated import resolution logic to cover this case.
I am not sure if it is the same underlying issue but supporting type aliases is more important. They allow us to deprecate APIs which we use quite extensively. I am not a fan of renaming imports myself so if you have to pick which one to implement first, I'd vote for type aliases :)
Originally posted by @thomaseizinger in #2647 (comment)
If an earlier version had a type (struct, enum, etc.) by some name, and the new version moves that type elsewhere but leaves a type alias in its place, that is not a breaking change. Currently, this scenario isn't detected, and we should update our simulated import resolution logic to cover this case.