Jiti investigation

Branch: next...jeppe/load-presets-with-jiti

We investigated using jiti for preset loading instead of the combination of esbuild-register+esbuild.

It was fairly easy to make it work, it's basically calling jiti.import(mod) and that just takes care of it. jiti automatically detects TS/ESM/CJS and compiles it when necessary.
However we also saw that it "overcompiling", eg. compiling CJS presets even though they should be importable fine as-is.
The workaround was to use the tryNative-option, which imports first, and only compiles if that fails. Unfortunately there's currently a bug (unjs/jiti#386) that means that it never falls back, but that was easy to workaround.

jiti is definitely a viable path here, but there are also some things that we're not fans of. It seems like jiti solves a lot of edge cases/weird situations that were historically problematic, but shouldn't be in modern Node, especially with require(esm) being a thing now. Modules are compiled into something like 'export default (...jitiTools) => ${actualModule}' where actualModule uses jitiTools instead of import, require and some other stuff. It also seems to be smart about replacing import.meta.url/__filename with something that still works even though the file is being compiled to some random temp dir.
None of this should be necessary today as long as we enforce that presets are always pure ESM or pure CJS (so not faux-ESM), where we can just import() them regularly. For TypeScript we really just need the types stripped away and/or compiled into ESM/CJS.

jiti currently adds ~2.5 MB to the core bundle due to it prebundling babel in, and we can't take esbuild out because we'll still be using esbuild to bundle the manager for the foreseeable future.

Currently we're pursuing the idea proposed in #31798 (comment), where we're registering a Node loader, that when it encounters a .ts preset it will compile it to ESM in place with esbuild. This is keeping it as close to the source as possible, which should make things easier to debug, less error prone, but also more strict.

Potentially we're too naive here, and being this close to source causes unforeseen issues. If so, jiti is a pretty good alternative.

cc @tobiasdiez

Uh oh!

M0: investigate the jiti or esbuild-approach #31798

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

M0: investigate the `jiti` or `esbuild`-approach #31798