New rescript-vscode@1.1.3 and vim-rescript@2.1.0 release!

Announcements
1

Hi everyone!

We just released the newest rescript-vscode and vim-rescript editor plugins with a few quality of life improvements:

Improved Jump to definition behavior (LSP)

Previously the vscode-lsp would always jump into a .resi instead of a .res file when both files were present, which was pretty disruptive for e.g. React developers when jumping between component implementations.

After several user feedback & discussions, the editor-lsp will now preferably jump to the .res file. We also added the jump to type definition capability in case you want to explicitly jump to the .resi file definition instead.

Better Rename support (LSP)

Previously we only supported renaming submodules. The lsp now supports renaming modules on the filesystem level as well.

vim-rescript

  • Better syntax highlighting for integer polyvariants and string interpolation
  • LSP upgrade to 1.1.3 to get access to the aforementioned features as well

Installation

  • For VSCode users, navigate to the plugins pane and check for any pending updates (it should show version 1.1.3).
  • For vim-rescript users, check the installation section.

Changelogs

You can find the full changelogs here:

Bonus: New ReScript icons in VSCode

Also, VSCode now ships custom made, builtin ReScript icons for .res and .resi files:

image
image1027Ă—764 61.2 KB

To get access to the new icons, update VSCode to the latest version.

20 Likes
2

Awesome news! Is there a plan to improve syntax highliting?

3

Great news! Was waiting for the new rescript vscode icons. Thank you !

4

Any update on the Outline support? I thought it was shipping on this version

5

@jorge It’s available, probably missed in changelog

6

is there a specific action required to enable it? The outline in my VSCode is still empty when I open .res and .resi files

7

Ok my bad. it was disabled again just before release since vscode shows stale data (vscode’s issue).

8

You are probably talking about JSX syntax highlighting, right? There’s no active work on that, but we’d consider any PR that doesn’t compromise on grammar correctness and doesn’t involve a lot of hard to maintain regexes. Biggest challenge afaik was collisions with generics and lower-cased JSX syntax. Also see this PR for inspiration.

The outline was disabled because it seems to be running into staleness issues (more details here). If you don’t care about a correct outline, you can monkey-patch it by going into your local plugin installation (~/.vscode/extensions/chenglou92.rescript-vscode-1.1.3) and uncommenting the following line:

2 Likes
9

aw ok, I will wait then. I appreciate it that you disabled it until it is :100:

1 Like
10

How can one use the intelligent renaming feature using vim? I don’t see any vim command available for it. Thanks!

11

Unfortunately there’s no rescript-vim-only command for that right now, so you’d need to use a vim LSP client to use it.

E.g. for coc-vim I created a binding like this:

nmap <leader>rn <Plug>(coc-rename)

Now with this configuration enabled I can put my cursor on top of e.g. a binding name, press \rn, and a dialog pops up.

1 Like
12

@ryyppy Having JSX syntax highlighting would be marvelous but as you pointed out, getting it to work without bloating the grammar file will not be that easy

I had in mind other small changes that might improve syntax highlight for example: punctuation or record/object.

Something like this in here: Add type, external, let word coloring && unit as constant by Faliszek · Pull Request #85 · rescript-lang/rescript-vscode · GitHub - Is highlighting those parts of the language is on yours roadmap?

13

We don’t have any concrete plans to the syntax highlighting right now (usually our editor-support updates are rather low-key in comparison to the rest of the v10 roadmap).

I’ll have a look how we could have some progress there that works for everybody.

2 Likes
14

This (related) issue is a big reason I’m hesitant to start introducing ReScript code to my codebase

15

One of the big reasons to not adopt ReScript syntax is because of a TM grammar? I thought your major blocking issues are on the syntactic / language philosophy / political level…

If that’s such a big problem, for now I’d just recommend taking one of the PR’ed (but flawed) highlighting grammars and set it up on a company level. I mean it’s just a single config file that can easily be installed with a single curl command (that probably needs to be re-run every few months when we release a new plugin version) :sweat_smile:

1 Like
16

It’s because of the screenshot I posted in my issue.

I am big on developer experience. I’ve worked on some very large codebases and our ReasonML codebase is well north of 80,000 lines of code now. Everyone is different, but I don’t understand how anyone can work on a large codebase when so much of the syntax is the same colour. It makes mentally figuring out what you’re looking at so much harder.

I also believe I will struggle to convince TypeScript developers on my team that ReScript has a better developer experience when the first thing they see is worse syntax highlighting.

TM grammars have a lot of problems, but the vscode plugin’s approach to highlighting is starting to come across as “perfect is the enemy of good”.

It’s a bit off topic here and I’ve been meaning to send you a private message about it. We’re approaching a go/no-go decision on rolling out something and while melange is a cool idea we can’t wait for it to get where we would need it to be. We need to make a choice and regardless of our other concerns ReScript seems to be the way to go.

That might work. I could even set up a command in our vscode workspace for it.

1 Like
17

100% this.

I am right now far from working on Rescript codebase (maybe in the future(?)) but back in the days working with Bucklescript was marvellous experience. But from marketing point of view, this experience is not something that is seen from new developers introduced to Rescript (especially without experience functional/typed safe language) right away, for me the biggest selling point was ease of refactoring, but to get to this point you have to have some code to refactor, and most of the people will not be keen to even try it, if they are thrown off by a little details like this, people are really picky these days, especially when they can not see a big picture of value that rescript might provide. First impression really matters. I am really looking forward to see Rescript taking mainstream someday. Not saying you should change your roadmap. You do what you do best, and you have amazing results. Just my point of view, I hope it might be somehow helpful

Ouch.

Just kidding :smiley:

Looking forward to next updates! :slight_smile:

1 Like
18

I think we all are! Our codebase is currently heading towards 50k LOC of ReScript. Highlighting is not perfect, but I think so far nobody threatened to migrate back to JS + Flow just because of the more colorful syntax.

Sorry if that sounded harsh. I wanted to be clear that all these changes are based on trade-offs and that it’s not that easy, otherwise the problem would have been solved a long time ago :smiley:

I think it’s at least as distracting having wrong highlighting than no highlighting… but that’s probably just an opinion. Really hard to tell what is the correct way to do it, especially in situations where not only the grammar can be faulty, but also the color theme itself may cause issues :dizzy_face:

Anyways, we’ll see how things will improve in the future!

2 Likes
19

Maybe once you’re deep into ReScript it’s fine. But in the last few years TypeScript has improved to the point where I’m getting a lot of pushback to the idea that ReScript is better. Little nitpicky things like this might be enough to sway the argument against it.

1 Like
20

I have been using the patch you suggested to show the outline and it works pretty decent. It is definitely more useful than without it.
I wonder if having this patch on locally will prevent VSCode from updating this extension