Autocomplete for custom Option module instead of Belt.Option

[DZakh]

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

[DZakh]

The same goes for arrays and other built-in modules

[zth]

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]

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]

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.