What are your major pains with the VSCode extension?

[zth]

I’m going to be helping out a bit with work on the VSCode extension together with @cristianoc. To better align our work and enable creating a small roadmap, we have the following question for all users:

What are the major pain points using the VSCode extension for you? What improvements/changes would bring the most benefit to you?

Please write down a brief and (preferably) actionable explanation of the pains you are experiencing. One pain per post (fine to answer multiple times). Please take the time to explain what you are experiencing, if possible what changes would fix it, and what benefits fixing it would bring to you.

If you agree with pain points written by other users, please like those posts, so we can get a grasp of how many experience the same thing.

Thank you in advance!

[mxthevs]

Syntax highlighting.

If we think in terms of developer experience, we have a nice language and a nice compiler, but it feels weird being greeted by a mostly white .res file. And when you look into how it was in Reason, it kinda feels like a downgrade as well. And this becomes a problem with larger React components. You can see examples below.

Rescript syntax

Reason syntax

It’s worth noting that the screenshots were taken while not using one of the recommended themes, but even when doing so, it does not get much better:

I think improvements in syntax highlighting will surely bring more goodness to the DX of Rescript.

[kevanstannard]

Snippet autocompletes

A feature that I use constantly is autocompletion of code. For example, typing “@r [Enter]” would autocomplete @react.component, or if I wanted to call a function SomeLib.theFunction I might only need to type “So [Enter] .th [Enter]” and it would autocomplete the module and function name.

However I need to use a different strategy when using keywords that have autocompletion configured. For example, I use switch frequently and I often type “sw [Enter]” which autocompletes the sample switch statement. I then delete the sample, and then type out “switch” in full. Same idea applies to external where I type “ext [Enter]” and it autocompletes with the sample, which I then delete and then type out “external” in full.

A great improvement for me would be if all keywords that have autocompletion snippets could have just the keyword only autocompletion as the default, and have the snippets available as other options.

For example:

Thank you

[nireno]

In the example above it would be helpful if the type hint would also drill down to show the variants of Next.Image.layout. Otherwise I need to manually lookup the type definition and even then using vscode’s “Go to type definition” doesn’t seem to work.

[mouton]

Matheus, my highlighting is much better than that…maybe something going on locally with your customizations? (Could be another issue, but highlighting is definitely better than youre seeing)

[Mng12345]

1. No tips for local variable if you do not save you file or if your context is not correct in syntax, it’s ok in typescript

in rescript, the type tips of variable y is not popuped. It only worked if you save your file.

in typescript, the tips is ok with or without saving the file.

Continuous updating…

Eg: the screen recorder gif is generated by the online recording website https://www.mnggiflab.com/screen-recorder, and compressed by https://www.mnggiflab.com/gif-compress

[spyder]

I’m with @mxthevs, highlighting is my #1. I still have plans to do a custom extension, my team has just been focussed on our TypeScript codebase recently. Work will resume on the ReScript code in a few months.

Problem with VSCode highlight

As I mentioned in the PR I plan to do a custom extension release with the highlight updates, I just haven’t been able to make time for it yet. The highlight stance of the official plugin is pretty clear at this point; I don’t expect it to change anytime soon. I also held back my company migration to ReScript because of this, and the response further demonstrates their stance: We have now migrated because I needed to start introducing new developers to it and that didn’t make sense to make the…

My #2 would be updating as I type rather than only on save. This isn’t feasible with the current extension design, of course, but it’s still high on my list as both TS and OCaml extensions are able to do it.

[thomaszdxsn]

Hope to support outline

[mxthevs]

Updating as typing would be very nice.

Also, there is another pain point that I just remembered: when you have an error, you lose hover information for everything below the error. Though I’ll have to admit that I don’t know how related to the extension this is.

[Lomand]

Can second that, when coding you’ll eventually run into some broken code, meaning I’ll lose all my type information, jump to definition, hovering and etc. arguably at the time I need the info the most, some kind of caching would be nice.

[zth]

Thank you all, this is great! Keep it coming!

[kay-tee]

Having to save a file to see error messages, using autosave as a workaround to this issue but then still having to manually save to have the code format on save.

[spyder]

@mxthevs

when you have an error, you lose hover information for everything below the error

This is also not possible with the current extension design. OCaml has had very smart people build technology for resume-after-error compilation (required for doing anything beyond an error) and buffer compilation (required for feedback before save). Unfortunately the ReScript IDE extension cannot leverage this work as far as I know.

The ReScript extension today mostly just pipes compiler output into the editor in a nice way; this is great for getting an IDE extension off the ground quickly but it doesn’t provide any groundwork for advanced features that go beyond what the compiler is designed to do.

The OCaml IDE tools used to work with ReScript, although only in ReasonML/OCaml syntax, but they dropped support for the version of OCaml ReScript is based on last year.

[nireno]

There’s a bug that causes files to appear multiple times in the file picker. Seems like It only affects rescript projects.

[mellson]

This one was solved recently by @cristianoc I guess the fix will be in the next release.

[nireno]

Some refactoring issues with “Rename Symbol”:

1. Can’t rename labelled arguments. The ~ seems to be captured and removed in the rename process effectively making it an unlabelled argument.
2. Can’t rename modules - i.e. If I Rename a module (at the filename level or otherwise) it would be great if it updated all references to that module.

[nireno]

“Go to definition” seems to work in some places but not others. In this example I can go to definition where the module is referenced within the function body but not for the reference in the type definition.

[zth]

Thank you all for your posts - keep them coming! Here’s a follow up on some of the pain points you’ve described.

Syntax highlighting

To address this in a sustainable way, we are going to experiment with semantic highlighting. Semantic highlighting means doing this: file contents -> parse to ReScript AST -> produce a set of tokens for highlighting from the AST.

While this will mean a larger up front cost for setting up the infra needed etc, we believe this is the best way forward. We’re hoping it’ll make tweaking the highlighting easy and correct, as it’ll be driven by the real parser and actual AST (which of course is 100% accurate), rather than attempting to reproduce parts of the parser via regexp etc.

Also, we’d be very happy if there’s community members who’d be interested in contributing a bit more in depth to this. We’re going to start by setting up the needed infrastructure and so on, but after that there’s likely going to be quite a lot of work in doing the actual highlighting (matching the various AST nodes and producing semantic tokens from them where appropriate). Most of the work is going to be in OCaml (in the analysis bin of the VSCode extension repo). Please reach out if you’re interested in contributing to this!

Feedback without saving

We hear you, and it would be wonderful to have. Unfortunately, this is an area full of complexity and trade offs. There’s still no decision if this is something that’ll be pursued at all, but if it were, it’d likely require potentially invasive changes to the compiler.

A short follow up, thank you all again for posting your pains and thoughts!

[amiralies]

TBH I don’t get why 100% accuracy in syntax highlighting matters. IMO good enough accuracy and enough coloring should be fine for all users.
We can achieve good enough accuracy with TM grammars and the maintenance overhead should be much lower than implementing semantic highlighting.

Another question is how good is the performance of semantic highlighting? i think they should be slower than normal TM grammars due rpc calls etc.

[Mng12345]

I think(may be most of the user’s of rescript) feedback without saving is the most important feature that the ide should have.