Support a standardised `source` or `typescript` runtime key

[terrablue]

What is the problem this feature will solve?

So I've gone through the backlog for similar proposals and read #58626, and while I understand some of the concerns, I'd like to offer a simpler, more minimal alternative.

My use case is that I write my tests in .ts files, and as of Node 23, I can simply run those tests without a compile step. But my test files usually import actual source files, something like this:

import impl from "#impl";

...

test.case("foo", assert => {
  assert(impl()).equals("expected");
});

And in my package.json file, I have something like this:

  "imports": {
    "#*": {
      "apekit": "./src/private/*.ts",
      "default": "./lib/private/*.js"
    }
  },

Where apekit is just my own custom condition that I use in tsconfig.json to get live jump-to-source in my editor. The problem is if I wanted to reuse that for the test runner, it's generally impossible to provide npx with a --conditions flag, leaving me with a bunch of ergonomically poor options:

1. Using NODE_OPTIONS: NODE_OPTIONS="--conditions=apekit" npx my-test-runner
2. Calling Node explicitly: node --conditions=apekit node_modules/.bin/my-test-runner

The latter is very fragile, particularly in monorepos. In addition, if down the import graph, a file in node_modules is used, this will bail out with Error [ERR_MODULE_NOT_FOUND], because the .ts file is usually not published and anyway not loadable from node_modules in Node, so I'd actually need to resort to something like --conditions=apekit,default.

So I was thinking, would it make sense for Node to generally support a "source" or "typescript" (I prefer "source") runtime key, which, if the importer was a TS file, automatically tries a "source" key if that exists in the importee's package, and otherwise falls back to the next key in the chain, and eventually to default?

I do realise this entire concern goes away if Node ever permits .ts files in node_modules, since you'd just do away with the build step entirely, but I don't see this coming in the near future or at all. This proposal bridges that gap, allowing me to quickly develop and retest without recompiling, which is usually the longest step. Runtimes that do load .ts files regardless of where they are, like Bun, do not have this issue.

What is the feature you are proposing to solve the problem?

See above.

What alternatives have you considered?

Using bunx to run my tests.