ts-node VS swc-node

I thought this was going to be a project like ts-node [1]

[1] https://github.com/TypeStrong/ts-node

The command specified in the app option uses ts-node by default, which is an execution engine for Node.js that allows you to run TypeScript code directly. The --prefer-ts-exts flag prevents ts-node from prioritizing precompiled .js files and will always import the TypeScript source code instead, if it is available. This is useful if you are also using tsc (the TypeScript compiler) alongside the app option. The bin/cdk.ts file is the entry point for our CDK app, which defines the main function that will be executed when the app is run.

If you want to write apps that run on Node.js I would suggest using Google’s TypeScript style guide. You can start using it by simply running npx gts init. I’d suggest that you start with this and run your apps using ts-node/ts-node-dev because it does not require an extra build step.

ts-node (“TypeScript execution and REPL for Node.js”)

Here is a relevant discussion and dev comment: https://github.com/TypeStrong/ts-node/issues/155

It does support ESM, with a --loader[1], but even with its SWC option it’s still significantly slower than the esbuild loader I’m working on. Unfortunately, esbuild isn’t totally compatible with tsc, so it’s not a drop-in replacement without plugins.

1: https://github.com/TypeStrong/ts-node#native-ecmascript-modu...

The process of compiling TypeScript source files into JavaScript code before executing them with Node.js can get a little tedious after a while, especially during development. You can eliminate the intermediate steps before running the program through the ts-node CLI to execute .ts files directly. Go ahead and install the ts-node package using the command below:

I tried suggested solution by https://github.com/TypeStrong/ts-node/issues/1007 but this causes problem with NestJS decorators:

swc-node is much faster. No typechecking but you can have that running as a separate process with typescript in watch mode. Basically never have to wait for compiles or typechecking checking then.

fwiw swc has an official loader: https://github.com/swc-project/swc-node

I actually just switched my team's app over to use https://github.com/Brooooooklyn/swc-node for our Jest tests, but if we're going to upgrade to Next 12 it'd be nice to reuse whatever's included there.

I actually upgraded my team's Jest config to use https://github.com/Brooooooklyn/swc-node a few weeks ago. However, our Jenkins CI agents run RHEL7, and neither of the Linux binary targets would run. The `x64-gnu` binary needed a `GLIBC_2_23` symbol when only 2.18 was available, and the `x64-musl` binary had no `musl-libc` on the machine. I don't own the Jenkins agents, so I couldn't install other deps myself.

I ended up building `musl-libc` from source on another RHEL7 agent, committed the `.so` to our repo, and added that to the `LD_LIBRARY_PATH` in our Jenkinsfile, and actually got that working.

I did see some mentions that Rust could build to target an older GLibc ( https://kobzol.github.io/rust/ci/2021/05/07/building-rust-bi... ), so I'm curious if Next is going to use copies of SWC built that way for better compat or if it will require more workarounds on my part.

I'm very curious if the Next SWC binaries