Jake Bailey

This is obviously exactly what I asked for (😄) and gets it "done" the quickest, but I'm curious if there are any other opinions about this in general. Is it...

Yeah, I guess it's no different than detecting calls to `require` and error/warn on ones which cannot be statically determined. It's just not quite as injectable as `require`. Just poking...

Just to prove this out to its full extent (and to procrastinate other work I didn't want to do), I polyfilled this API using `--require` and was able to get...

Something on `process` sounds totally fine to me; I also didn't realize when writing the above that you could also do: ```js const require = process.getBuiltin("node:module").createRequire(import.meta.url) ``` And be no...

I think the only concern I have for a `process`-based approach is how bundlers won't recognize these as being "imports" per se, so may not be able to shim them....

I'm working on a proof of concept; my quick hack for now (until I can get all of it as ESM) is to use a `--require` preloaded script to patch...

So, that was a lot easier than I expected. ```console $ cat testRequireESM.cjs // Inject this into the process so that TS can synchronously require stuff. process.createRequire = require("node:module").createRequire; const...

In the first one, you are already importing `process`; is this actually a conditional? For the latter, you can actually export from ESLint configs a Promise, such that you can...

Alternatively, it'd be super helpful if all of this stuff were piped to stderr.

That's unfortunate; I avoid using the cache feature of the action because I'm nervous of mixing different major npm versions' caches. Having a corepack opt-in would compose well there, but...