Favour public alias over internal definition for types in the language server

[ghivert]

Recently I figured out the LSP correctly resolves types with qualified names, but it follows every aliases. So every time you hover over an Element(a) in Lustre, the LSP actually resolves to vdom.Element(a), even when you explicitly imports Element from lustre/element.

This is an understandable behavior, because Element is defined as

pub type Element(msg) = 
  vdom.Element(msg)

However, such a behaviour is a bit disappointing, because it does not resolves to what you're looking for, but rather to what it is under-the-hood. Typically, going to definition with LSP brings us to lustre/internals/vdom.gleam, which is part of the hidden API of Lustre. Ideally, the LSP should stop resolving types to the alias, and let the user continue diving in the code if needed, which is simple enough thanks to go to definition.

In the same context, when using the LSP to add type annotations, it completes everything with vdom.Element(a), which is rather disappointing too.
A workaround can be used by using import lustre/element.{type Element}, so the LSP now completes types in an unqualified way — with Element(a).

[lpil]

Thank you! Yes, we want to improve this for sure.

I think we could possibly implement this enhancement without lifting aliases into the type system, which would be an easier job that has fewer far-reaching impacts in the rest of the language.

[GearsDatapacks]

Currently, the language server prints the type alias if it's defined in the current module, or imported. However it doesn't yet have enough information to do it if it simply exists somewhere arbitrary. Perhaps a next step could be to also do this if you import the module which defines the alias.