Reformat ReScript in place

1

How can *.res files get formatted in place? The only solutions I’ve seen are to convert *.re files to *.res files.

$ refmt.exe --in-place File.res
    
refmt: Cannot determine default implementation parser for filename

The below is a workaround. I’m hoping I’m missing a better, simpler solution.

$ find . -name '*.res' -exec sh -c 'bsc -format $0 > $0.tmp && mv $0.tmp $0' {} \\;
1 Like
2

I would recommend to use this extension if you use vscode:


It’s still in early stage but it already handles formatting.
1 Like
3

We don’t currently support in-place formatting in the CLI. And yeah the plugin above works.

4

Another option. Install moreutils (eg: brew install moreutils) and:

bsc -format src/Test.res | sponge src/Test.res
1 Like
5

Thanks. I’m trying this based on your pointer. Looks like -color is not applicable to -format, BTW.

"rescript:format": "find . -type f \\( -name '*.res' -o -name '*.resi' \\) -exec sh -c 'bsc -format {} | sponge {}'  \\;",
6

I’ve edited joakin’s post. -color flag for formatting doesn’t exist and doesn’t make sense =)

2 Likes
7

It would be nice to have an --in-place equivalent so formatting can be forced as a pre-commit hook (like lot’s of team do this day with js/prettier). I miss that from reasonml.

8

We noticed that bsc -format doesn’t exactly match the result of “format on save” in vscode. I haven’t looked in detail at the differences or what is happening yet.

9

It just shells out to bsc -format: https://github.com/rescript-lang/rescript-vscode/blob/3637c48c8e8bdcfcc5328e310ab4127498ae9a23/server/src/server.ts#L434

If you’ve got a repro, file an issue please. Thanks!

Apologies to @joakin; I see where he took the -color never from: https://github.com/rescript-lang/rescript-vscode/blob/3637c48c8e8bdcfcc5328e310ab4127498ae9a23/server/src/utils.ts#L72, though I’m not sure why I added that flag…

It would be nice to have an --in-place equivalent

We can consider it soon now that the CLI redesign is coming out =D. I personally can’t stand any slowdown during commit, so no pre-commit hooks for me ever. Don’t wanna encourage folks to do so and lose sight of our perf goals, but I get the convenience.

5 Likes
10

Some people may not commit often and may be interested to lose a few ms when “committing” (the word is strong enough to be ready to way 0.5s after running a command) to ensure formatting of the code across the codebase & team mates.

11

Meanwhile a flag exist, I am doing this stupid thing:

resfmt-in-place.sh

#!/bin/sh
bsc -format $1 > $1.tmp && mv $1.tmp $1

(don’t forget to chmod +x ./resfmt-in-place.sh)

And in lint-staged config

  "lint-staged": {
    "*.{res,resi}": [
      "./resfmt-in-place.sh"
    ]
  },
12

It’s not about how many ms lost; it’s about the orientation of whether to make things faster or slower. For example, you’re enjoying a compilation performance that’s the result of us worrying about perf every change. 500ms once every half year, over five years, is 5 seconds, which is incidentally around how slow some of our competitors are.

Anyway this isn’t the right thread for me to yak shave about software philosophy. Like I mentioned, we’re considering it for the new CLI.