Resolve @rescript/runtime

[nojaf]

Making some progress here. This is an alternate take on what @cknitt had in #7637.

In short:

• bsc also gets a -runtime-path parameter with the location of @rescript/runtime.
• cli/rescript.js determines this in resolvePackageRoot.js. It leverages the JavaScript runtime and finds @rescript/runtime via import.meta.resolve, with fallbacks for Deno and Node require. I prefer doing these shenanigans on the JavaScript side so we can easily ask users to try tweaks in that script if needed.
• cli/rescript.js sets RESCRIPT_RUNTIME, analogous to RESCRIPT_BSC_EXE, and Rewatch will consume it to set the -runtime-path argument.
• In Rewatch, we first try RESCRIPT_RUNTIME and use the regular package resolver as a fallback. It is not perfect, but should cover many cases where @rescript/runtime is in one of the three locations checked by helpers::try_package_path.
• With the Rewatch change, we stay consistent without introducing an extra crate like oxc_resolver. Users calling npx rescript will have the runtime resolved by the JavaScript runtime, so in practice only ReScript maintainers will run Rewatch directly.

edit

I originally set up tests that run ./cli/rescript.js with different runtimes and package managers, but that doesn't reproduce real user problems because it always runs against this repository instead of separate test repos. I want to create a lightweight testing repository instead. That will better match what end users actually have and make it much easier for people to contribute samples. The entry bar for contributing examples in this repo is higher than I'd like.

[pkg-pr-new]

Open in StackBlitz

rescript

npm i https://pkg.pr.new/rescript-lang/rescript@7858

@rescript/darwin-arm64

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/darwin-arm64@7858

@rescript/darwin-x64

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/darwin-x64@7858

@rescript/linux-arm64

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/linux-arm64@7858

@rescript/linux-x64

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/linux-x64@7858

@rescript/runtime

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/runtime@7858

@rescript/win32-x64

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/win32-x64@7858

commit: 88b0483

[nojaf]

Okay, like I mentioned on Discord, the remaining crux is that Rewatch needs to find @rescript/runtime when the tooling invokes the compiler via rescript compiler-args.

That direct invocation doesn't set RESCRIPT_RUNTIME the way cli/rescript.js does, so the runtime still won't be found for Deno. For most users this will work, but it's not bulletproof.

So what's next? I'm thinking of scanning for the runtime on the tooling side. If we know the workspace directory, a small traversal should find it.

I prototyped this with the following script: https://gist.github.com/nojaf/f3c26f2354b1609366bb51c59bfed20e

To run:

node find-runtime.mjs <path-to-your-project>

The script includes a fallback for Deno and worked for me on every project I tried.
In the IDE, if nothing is found, show a message saying either node_modules haven't been restored or the project uses an unusual location. Ask the user to configure it via settings.json and let us know.

This is my current thinking: please try the script and report any cases where it failed to find a runtime or where performance was poor. On my Mac, all project runtimes were detected in under 5 ms. Same on Windows.

[nojaf]

Okay, rescript-lang/rescript-vscode#1125 is ready and I did some thorough testing on this. (ReScript 11, ReScript 12 with legacy build, ReScript 12 with Rewatch).

As for the extra tests, see description of PR.

[cknitt]

Great work!