Re-formality issue while upgrading rescript to v10

1

Hey @alex.fedoseev , I was upgrading rescript to its latest version i.e. v10.1, and upgraded re-formality to its latest version i.e. v4.0.0-beta.18 but when I ran my application, for some reason validations were not working properly. For example, in one case, where the entered data was correct, it threw an error. Can you please help here? Would really appreciate it.

2

Hi @bhavyamm, I’ll be updating the compiler in our projects in the upcoming weeks and will look into this.

1 Like
3

Hi @bhavyamm , just out of curiosity can you create a minimal repo with the bug and file an issue, so that anyone who is interested can try fixing it.

4

Hey @alex.fedoseev, did you get a chance to look into this?

6

hey @a-c-sreedhar-reddy , sure

7

@bhavyamm I just updated re-formality but there weren’t any changes to the library code. What I faced though is that after ReScript update, regexes were silently broken. Check out this changelog section: rescript-compiler/CHANGELOG.md at master · rescript-lang/rescript-compiler · GitHub

Let me know if it helps.

8

Technically it was a fix. But certainly a breaking fix.
Not sure if there’s a way to give a warning, as the intent is ambiguous?

9

I’m not sure if it’s possible, but to make it less silent, it might make sense to enable a special warning when the compiler encounters a potential issue. This warning can be turned off via annotation / config (as all other warnings) and after 1 or 2 major versions turned off by default or removed completely.

10

What’s an example of potential issue?

11

Here is the example where the validation was broken and I noticed it only by manually checking UI: Update deps · shakacode/re-formality@a8e4c4e · GitHub

12

The question is about intent: how does the compiler know the used did not intend to match this:

%re(`/.*@.*\\..+/`)
13

It doesn’t. It just brings attention to a possible issue that is not necessarily an issue. The dumb simple option might be to warn on each \\. Maybe there are other scenarios.

Personally, I have high trust in sound compilers and their ecosystems. So when I bump deps, I am mainly focused on compiler output. Means if it compiles, most likely it works. I read human written announcements, but with much less attention than in case of unsound languages. So, in this case, I would prefer a false alarm in a shape of a warning instead of radio silence because 2 out of 2 there were actual issues that I discovered at runtime.

2 Likes