How to quickly find the version of R that webR runs?

[HenrikBengtsson]

One can quickly (~65 ms) identify the webR version using:

$ node --input-type=module -e 'const t0 = performance.now(); import { WebR } from "webr"; const webr = new WebR(); console.log(webr.version); console.log(performance.now() - t0); process.exit(0);'
0.5.5
65.4388900026679

Is there a way to quickly identify the version of R that the current webR provides?

The only way I know is to launch webR and call getRversion(), but that is slow (~2.5 seconds), e.g.

$ node --input-type=module -e 'const t0 = performance.now(); import { WebR } from "webr"; const webr = new WebR(); await webr.init(); await webr.evalR("cat(as.character(getRversion()))"); console.log(performance.now() - t0); process.exit(0);'
4.5.1
2427.1900480017066

PS. My goal is to identify the "x.y" version of R in webR, such that I can install rwasm packages to a specific R package library on host, e.g. ~/.R/emscripten/4.4 and ~/.R/emscripten/4.5.

[georgestagg]

The majority of that time will just be awaiting for webR to init(): spinning up the new Worker, compiling the WebAssembly module, and starting up R itself.

I think we should add this to the webr instance, similar to webr.version. We know the R version at build time in any case, since our patches are relative to a specific release of R, so we could easily add a webr.baseRVersion or similar.

In the meantime, if you're brave enough to be really cheeky you could read out the version directly from the installed R WebAssembly binary:

node --input-type=module -e 'const t0 = performance.now(); const version = fs.readFileSync("./node_modules/webr/dist/R.wasm").toString().split("\n").find(line => line.includes("Version: ")); console.log(version); console.log(performance.now() - t0); process.exit(0);'
Version: 4.5.1
121.35475

This works because the R Wasm binary contains a minimal filesystem for launching R, including the file /usr/lib/R/library/base/DESCRIPTION. Nasty, but it works.

[HenrikBengtsson]

Thanks for detailed explanation and the "hacky" workaround - it's alright.

I think we should add this to the webr instance, similar to webr.version. We know the R version at build time in any case, since our patches are relative to a specific release of R, so we could easily add a webr.baseRVersion or similar.

Yes, that would be useful.

After writing here, I realized that it would useful with some additions details from R.version;

$ str(R.version)
List of 14
 $ platform      : chr "wasm32-unknown-emscripten"
 $ arch          : chr "wasm32"
 $ os            : chr "emscripten"
 $ system        : chr "wasm32, emscripten"
 $ status        : chr ""
 $ major         : chr "4"
 $ minor         : chr "5.1"
 $ year          : chr "2025"
 $ month         : chr "06"
 $ day           : chr "13"
 $ svn rev       : chr "88306"
 $ language      : chr "R"
 $ version.string: chr "R version 4.5.1 (2025-06-13)"
 $ nickname      : chr "Great Square Root"
 - attr(*, "class")= chr "simple.list"

This is because I'm interesting in being able to specify library paths with "conversion specifiers" as describe in help("R_LIBS_USER", package = "base"). This would allow me to host the webR R user package library on host at ~/R/%p-library/%v, which would expand to ~/R/wasm32-unknown-emscripten-library/4.5 with webR 0.5.5, based on:

• ⁠%V⁠: R version number including the patch level (e.g., ⁠2.5.0⁠).
• ⁠%v⁠: R version number excluding the patch level (e.g., ⁠2.5⁠).
• ⁠%p⁠: the platform for which R was built, the value of R.version$platform.
• ⁠%o⁠: the underlying operating system, the value of R.version$os.
• ⁠%a⁠: the architecture (CPU) R was built on/for, the value of R.version$arch.

When webR eventually moves to R 4.6.0, ~/R/%p-library/%v will automatically move to ~/R/wasm32-unknown-emscripten-library/4.6.

PS. My current strategy is to pay the price and grab R.version from webR and then memoize the results. I guess I could also cache to file.

PS 2. My ultimate wish: It would be super neat if WebR() could support environment variables R_LIBS_USER and R_LIBS_SITE and bind those webR folders to host. I think R would automatically take care of those env vars at startup. But they will be ignored, if the directories they expand to do not exist. I don't think this is currently possible, because any webR.FS.mkdir() and webR.FS.mount() have to come after webR.init(), at least as far as I understand it. So, for now, the best approach is to set .libPaths() manually.