search

rescript-lang / rescript-vscode

Official VSCode plugin for ReScript
MIT License
329 stars 56 forks source link

Autocomplete for custom Option module instead of Belt.Option #909

Open DZakh opened 9 months ago

DZakh commented 9 months ago

We have a vendored stdlib which exposes the Option module, and it would be nice to get autocomplete for it instead of Belt.Option.

image
DZakh commented 9 months ago

The same goes for arrays and other built-in modules

zth commented 9 months ago

This would be a good configuration option and I'm really not against the idea (would enhance the DX for sure), but the problem is where we should have the user put this type of custom configuration. rescript.json? Somewhere else?

woeps commented 9 months ago

Is a config even necessary?

(Note, that I'm not aware of the actual algorithm used: Would autocomplete suggest other Modules after Belt? How about for rescript 11? Would it suggest Core?)

Could just heuristics be used? Like calculate a "distance" of a possible suggestion to the current file and order suggestions according to shortest distance. Similar to:

  1. Submodule in the same file
  2. Globally opened in rescript.json
  3. File in the same dir
  4. Standard Lib / Builtin
  5. Dependencies
zth commented 9 months ago

The current heuristics are very simple and rely on just checking whether Core is opened or not, then decides on what module to complete from for each builtin type.

This is very simple which also means it's really fast. No need to read any actual type information from files that you won't end up using. And that's the problem with an approach like above - you'd end up reading type information (which is expensive) for many many files. And some general issues around how to decide what module to pick, and so on.