ts-node VS sucrase

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:

Thanks. As for the code compilation, that can be tested and seen in https://sucrase.io/

The demo page is only to show how we can transpile JSX in browsers.

Thanks u/OutlandishnessKey953, the playground built with React, Docusaurus(https://docusaurus.io/), CodeMirror(https://codemirror.net/), Sucrase(https://sucrase.io/), etc.

Hi, Sucrase author here.

To be clear, the benchmark in the README does not allow JIT warm-up. The Sucrase numbers would be better if it did. From testing just now (add `warmUp: true` to `benchmarkJest`), Sucrase is a little over 3x faster than swc if you allow warm-up, but it seemed unfair to disregard warm-up for the comparison in the README.

It's certainly fair to debate whether 360k lines of code is a realistic codebase size for the benchmark; the higher-scale the test case, the better Sucrase looks.

> worse it disables esbuild and swc's multi-threading

At some point I'm hoping to update the README benchmark to run all tools in parallel, which should be more convincing despite the added variability: https://github.com/alangpierce/sucrase/issues/730 . In an ideal environment, the results are pretty much the same as a per-core benchmark, but I do expect that Node's parallelism overhead and the JIT warm-up cost across many cores would make Sucrase less competitive than the current numbers.

First, npm i -D sucrase to install sucrase. Now you can do node -r sucrase/register ./index.ts to run TypeScript code directly with Node.

As you might know there are a lot of Javascript bundlers out there, such as webpack, sucrase, parcel, rollup and etc. Bear in mind, not because they have thousands of stars on Github that means they're the best. sometimes new libs are as good as the popular ones but they're still building up their image/popularity in the community. what I bring today is a not sooooo, popular JS bundler called esbuild.

Sucrase JS was 2x the speed of esBuild and 50% faster than SWC last I checked.

Webpack does way more than esbuild, including running a typechecking compiler instead of just transpiling, running compilers able to downlevel emit to ES5 and providing a deep plugin architecture allowing you to hook into any bit you like. But yes, it hasn't been designed with speed in mind - it has been designed with maximum extensibility instead. Its the same reason why Babel is slow compared to sucrase (written in JS, currently faster than SWC and esbuild but doing somewhat less - https://github.com/alangpierce/sucrase)

tsc has in fact been designed with speed in mind (I've been following the project since before it ended up on GitHub). Going beyond 1 order of magnitude performance improvement is highly unlikely.