Cache `getExePath()` for performance reasons

[tido64]

Would it be possible to have getExePath() cache its result so we don't have to do all this lookup every time tsgo is invoked? The platform and arch rarely changes once installed on disk.

In one of the repositories I'm maintaining, we've inlined what tsgo.js does and added caching on top of it. We're not a very big monorepo, but this shaved off several seconds for us.

[jakebailey]

Caching where?

It's pretty intentional that we don't have a postinstall. Otherwise you're implying we cache something during first run, which I'm not sure how to do without touching node_modules (which is a little suspect).

I'm not sure what's slow about our current code, though. It's certainly not the platform checks, which should be instant...

(Ideally we could tell the package manager to link a specific binary, but no such feature exists, hence the wrapper...)

[jakebailey]

If the import is that slow, we could switch to using plain FS lookups, since peer deps must be "peers" in a parent dir...

[nileshpatil6]

Sorry about the noise on #3450, the FS walk approach was wrong as you pointed out.

Looking at this again, the simplest correct fix would be to just add a module-level cache around the existing import.meta.resolve/require.resolve logic without replacing it. That way we avoid reimplementing npm's resolution and just pay the cost once per process. Would that be worth a PR or is there a reason it would not help in practice?

[jakebailey]

The original issue filer says that it's for multiple invocations of tsgo, so that form of cache would not help anything.

Unfortunately, @tido64 did not show the code for what they mean, and my best guess is that paths are being hardcoded somehow.

[tido64]

Sorry for not getting back to you. This issue dropped off my radar.

Like you probably suspected, we store our path in node_modules/.cache/tsgo. But I don't think it matters much where you store this file, whether it's in node_modules or tmpdir, the fact remains that your current architecture doesn't change. We use your getExePath if it doesn't exist and persist it to disk. You can see the implementation here: https://github.com/microsoft/rnx-kit/blob/main/scripts/src/commands/build.js#L46

[jakebailey]

I'm beyond surprised that this helps at all, given both hit the disk and "importing a module" should be the least of anyone's concerns. I'll have to try it and see...

[jakebailey]

With:

#!/usr/bin/env node
"use strict";
const path = require("path");
const pkg = "@typescript/native-preview-" + process.platform + "-" + process.arch;
const exe = path.join(
    path.dirname(require.resolve(pkg + "/package.json")),
    "lib",
    "tsgo" + (process.platform === "win32" ? ".exe" : ""),
);
if (process.platform !== "win32" && typeof process.execve === "function") {
    try { process.execve(exe, [exe, ...process.argv.slice(2)]); } catch {}
}
try {
    require("child_process").execFileSync(exe, process.argv.slice(2), { stdio: "inherit" });
} catch (e) {
    if (e.status) process.exitCode = e.status;
    else throw e;
}

In CJS, this improves things a bit.

Caching the actual path on disk does not appear to help much at all in my testing...