We recently updated and published rescript-vscode (1.0.7) and vim-rescript (1.4.0) with our newest autocompletion features, and some other small tweaks.
Installation
VSCode: Go to your extensions tab and update your rescript-vscode installation.
Please note: value-> will autocomplete only when value has type M.t for some type t and module M. More concretely, this means that [1, 2]-> does not show you suggestions for Belt.Array.xyz because [1, 2] is of type array<> and not Belt.Array.t. Consider this an early iteration of this feature, which will be improved in the future.
Function Label Autocompletion
Our supported editors will now also autocomplete the names of labeled arguments used in a function call:
(As always with our IDE integration, first make sure to compile your program with the labeled function before trying to use the autocompletion, otherwise our editor-support doesn’t know the labels exist)
Support for the upcoming rescript npm package
We are currently in the process of migrating to our new rescript npm package, so we made sure that our IDEs will continue to work, no matter if you are still running on bs-platform, or already using the new rescript package.
Changelogs
For smaller fixes / tweaks, check out the relevant Changelog files:
This is great, I would say that I got used to coding without much of an IDE but it’s honestly great to get autocomplete back. The support for -> is a great idea and super useful, all the time!
Support for builtin array<> can be added in a number of ways. One of the questions is where it should take candidates for the autocomplete. Even restricting to t-first cases, there are both Js.Array2.foo and Belt.Array.foo. We’ll make a decision here for now and clean up these aspects later.
I bet a lot of teams have their own Array module which probably includes Belt.Array and maybe adds something from Js.Array2 and some custom helpers. We definitely do.
If you want autocomplete for your own MyArray module, just define type MyArray.t<'a> as array<'a> in it. Then type inference will get that type and autocomplete will fire.
Sorry for bikeshedding but… I understand the labeled function arguments improvement but what does the -> change actually improve? It’s making a strong assumption about the way the code is structured (and this assumption is not always correct) and the “big” win is not having to type a module name?
What about scenarios like the following?
module Hello = {
type t = {name: string}
let name = t => t.name
}
module HelloExt = {
let name = (t: Hello.t) => t.name
}
let a = {Hello.name: "hello"}
a->HelloExt. // I know what module I need, I need help with the function
I think, in general, one knows what type they are using at the moment so typing the module name is not a problem. Then they can use the completion to find a particular function within the module.
I apologize for bikeshedding. Just trying to figure out the actual benefit for this addition
I think it’s important to explore this kind of autocompletion functionality. Even if you don’t see any value for it right now, it will probably be a really important feature for others.
That said, it’s not intended to overrule module autocompletion with -> autocompletion. Will be fixed soon.
My message did sound like “why bother” I give you that. But it was not my intention. As long the original autocomplete functionality is there I’m only happy that there are features that might help with Rescript adoption
Seconded. For my style of developing, this is a pretty big help already, and I imagine it’ll be really nice once built in types can be autocompleted too.
Autocomplete for built-in types and some literals: https://github.com/rescript-lang/rescript-editor-support/pull/107
In case someone is interested in trying it out before the next release. (Requires taking the binary from CI and replace the one that comes with the vscode extension).
