You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 :)
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: