esno VS TS-ESNode

Love this project, used it quite a bit. However I always opt for using esno[1] instead, merely because of the name; having two tools share the same name throws me off.

[1] https://github.com/esbuild-kit/esno

Next, I thought well nx is not gonna work for now, so let's keep looking for an alternative to ts-node. Oh look, there is this https://github.com/esbuild-kit/tsx. It natively understands path aliases, no need for any flags. Oh wait...it doesn't do any type checking like ts-node. WHAT? why would anyone execute typescript without type checks during development?.

I’ve generally found tsx to be better/less hassle than ts-node

https://github.com/esbuild-kit/tsx

For just running Typescript files you have (both for dev and prod) https://github.com/esbuild-kit/tsx with command is generally easier then using ts-node + some file watcher or compiling to js

Just use tsx: https://github.com/esbuild-kit/tsx

I've been using tsx, which is like ts-node except it uses esbuild under the hood. It's been pretty great. Super speedy.

And compared to esno?

Typescript with TSX for development

Take a look at Typescript runners like ts-node or esno (https://github.com/antfu/esno)

CommonJS is a great module system if you're using JS for scripting Unix (which it excels at). Is there a good reason to use ESM though? I've been half-joking that it's the "extinguish" phase of Microsoft's EEE strategy for JS.

I know one legitimate reason is "tree shaking" (source-level LTO when bundling modules). Dumber, static import/export statements probably simplify that in some way. However ESM destroys the isomorphism between JS modules and the filesystem.

One change that ES modules introduced, I think, for no other reason than to be backwards incompatible, is changing the behavior of the default export (`export default foo` transpiles down to `module.exports.default = foo` instead of `module.exports = foo`).

Other "ohai guys this is the new normal now" kinds of changes are making the dynamic imports async-only (after not supporting them for a while) as well as changing the behavior of module resolution.

And the cherry on top is called TS-ESNode: https://github.com/K-FOSS/TS-ESNode because TypeScript modules and ESM are the same thing yet you need to somehow find this third-party shim which is required for them to work together at all. It's enabled by wrapping the interpreter, just like Yarn2's new dependency resolution.