Skip to content

Completions defined in editor.autocomplete don't work on type aliases #7501

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
mediremi opened this issue May 22, 2025 · 2 comments
Open

Comments

@mediremi
Copy link
Contributor

mediremi commented May 22, 2025

I have a module BeltMapX with utility functions for working with Belt.Map.t.

I tried to set up autocomplete for pipe completion in rescript.json like so:

"editor": {
  "autocomplete": {
    "Belt.Map.t": ["BeltMapX"],
  }
}

This didn't work so I did some debugging in analysis/src/CompletionBackEnd.ml, and it turned out that mainTypeId is actually Belt_Map.t.

let mainTypeId = TypeUtils.findRootTypeId ~full ~env typ in
let typePath = TypeUtils.pathFromTypeExpr typ in
match mainTypeId with
| None ->
if Debug.verbose () then
Printf.printf
"[pipe_completion] Could not find mainTypeId. Aborting pipe \
completions.\n";
[]
| Some mainTypeId ->

Updating my rescript.json config to use the unaliased type, as below, worked.

"editor": {
  "autocomplete": {
    "Belt_Map.t": ["BeltMapX"],
  }
}

Would it be possible to make the completions backend handle type aliases so that "Belt.Map.t": ["BeltMapX"] works?

@zth
Copy link
Collaborator

zth commented May 22, 2025

Hmm, it's certainly possible, but I wonder if it's clear enough. How would you like it to work for it to be clear/usable enough?

@mediremi
Copy link
Contributor Author

mediremi commented May 22, 2025

Preferably, the type alias would be transparently converted to the type it points to. But I would also be fine with the compiler emitting a warning like Invalid editor.autocomplete value: Belt.Map.t is an alias for type Belt_Map.t and then having to manually update rescript.json with the correct value.

Maybe an alternative way of fixing this could be having the LSP provide type alias information. It would be nice if when I hover over e.g. a Belt.Map.t value in VS Code, in addition to seeing type Belt.Map.t<'key, 'value, 'identity>, I would see something like Alias for type Belt_Map.t and therefore know to use that instead.

This would be particularly helpful for something like Dom.element, where I had to follow the chain of type element = element_like = node_like = eventTarget_like to figure out the correct editor.autocomplete value.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants