fix Start Code Analysis: use correct binary paths for ReScript v12+

[cristianoc]

More in style with the existing codebase.
Just add one more path to try, on top of all the others already tried.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: fc05c532fb

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[nojaf]

I'm not going to claim what we have today is the crown jewel or can't be improved, but this PR makes too many assumptions and misses a lot of recent developments.

Makes me wonder whether we should add a rescript binaries command that outputs all the info as JSON to stdout. That would essentially be what compiler-info.json contains today, but without invoking a full build.

Can you elaborate what wasn't working for you? This feels more like a rewrite for the fun of it, presented as "v12 never worked so here is the fix." We fixed a lot over the summer, so I'm curious which setups failed and what exactly went wrong.

[nojaf]

compiler-info.json is NOT at all legacy.
It is a ReScript (Rewatch) 12 feature that has a significant higher accuracy to determine the bsc_exe value.

It gets written after a rescript build and has significant accurate information about the compiler and runtime. Respecting environment variables that can override these locations which is crucial for local testing.

https://github.com/rescript-lang/rescript/blob/66ba3f8d7769c9d21084f8e3e3acd1c622d56514/rewatch/src/build.rs#L410

[cristianoc]

I'm not going to claim what we have today is the crown jewel or can't be improved, but this PR makes too many assumptions and misses a lot of recent developments.

Makes me wonder whether we should add a rescript binaries command that outputs all the info as JSON to stdout. That would essentially be what compiler-info.json contains today, but without invoking a full build.

Can you elaborate what wasn't working for you? This feels more like a rewrite for the fun of it, presented as "v12 never worked so here is the fix." We fixed a lot over the summer, so I'm curious which setups failed and what exactly went wrong.

The original intent is actually quite simple.
"Start Code Analyzer" does not find the correct binary path (and it looks for the wrong binary anyway), falls back into some "use what's included in the extension", then crashes. Instead of simply reporting that the binaries were not found.

The original intent is to at least eliminate the v12 vs other versions complexity. And fix code analyzer binary lookup.
Clearly the result simplifies too much at the moment.

Is there a spec anywhere of what binary resolution should look like? Is there a reason why it should be different than what the compiler does (if not, then the compiler code could be the spec). Even a few tiny example projects checked in that "should not break" could work as substitute for a proper spec.

Otherwise, "change the existing code as little as possible or something will break" is the only thing that can be done at the moment. Which is one way to do the PR if there's no alternative.

[cristianoc]

moved to different PR for simplicty.

[nojaf]

Is there a spec anywhere of what binary resolution should look like?

Not really, this is mostly the consequence of situation x or y was not working.

The

    const targetPackagePath = path.join(
      fs.realpathSync(rescriptDir),
      "..",
      `@rescript/${target}/bin.js`,
    );

part was a recent addition.

If we had that sooner, we probably would not have done the compiler-info.json lookup.