perf: always use jiti/native in Deno

[lucacasonato]

Deno already supports ESM/CJS interop, TypeScript, and tsx out of the box. It also doesn't have loader hooks for ESM anyway, so there is no point in trying to do that in Deno. Instead, we can always pass through to the native runtime functions.

Closes #402

[pi0]

Thank you for the PR. I see Deno native compat got much better 🚀 (updated tests)

However, there are a couple of (non-standard) behaviors in jiti that are still not covered (you can test with pnpm test:native:deno). Because of this issue, we kept native mode opt-in (by consumer via explicit subpath). Also please consider jiti does not depends on ESM loader hooks (other than for jiti/register)

We have another layer of fast-path to use the runtime native loader (tryNative). We enable it by default for Bun, I think it would be worth a shot to enable it also for Deno. It is 1) safe and 2) by the amount of native coverage, I think it should contribute to improving runtime perf. (I'm only worried if, in this case, Deno/Jiti users might start to see new warnings like implicit extensions)

[lucacasonato]

That makes sense. Alternatively if you can lazy load things like babel only if they are actually used that may help too. Right now jiti is loaded by @tailwind/node unconditionally, and it contributes about 250ms to startup time from my measurements.

[pi0]

Yes exactly was going to write same suggestion in #402 😆 Extra loading of babel only is needed if we actually need transform (native fails > cache misses > transform needed)

[pi0]

General dist perf improving by #404 and landing lazy transform in #405

Closing this PR since we can't force resolve to jiti/native but totally open to track idea of enabling tryNative for Deno considering there won't be additional warnings. Lets track via #402