Important Resources:
The tsx documentation includes the following points about what makes it a better option than ts-node:
- tsx is zero-config because it has smart detections built in. As a runtime, it detects what's imported to make many options in tsconfig.json redundant—which was designed for compiling matching files regardless of whether they're imported.
- It seamlessly adapts between CommonJS and ESM package types by detecting how modules are loaded (require() or import) to determine how to compile them. It even adds support for require()ing ESM modules from CommonJS so you don't have to worry about your dependencies as the ecosystem migrates to ESM.
- At the core, tsx is powered by esbuild for blazing fast TypeScript compilation, whereas ts-node (by default) uses the TypeScript compiler.
Important functionality differences:
ts-nodeincorporates type checking,tsxdoes nottsxhandles package types automatically,ts-nodedoes not
Our usage of ts-node |
tsx equivalent |
Description |
|---|---|---|
node -r ts-node/register |
node --import tsx |
We use node directly to run .ts files by registering/importing a ts interpreter. (See NOTE below). |
nyc mocha -r ts-node/register |
nyc mocha --import tsx |
Used for testing typescript projects. |
Note
node --import tsx adds support for both Module and CommonJS contexts. To only import one, you can use node --import tsx/esm or node --require tsx/cjs.
node -r ts-node/register only supports a CommonJS context, node --loader ts-node/esm must be used for projects that are type Module.
On average tsx was faster, (about twice as fast on medium sized projects), than ts-node. tsx also includes a watch option which automatically reruns when the codebase is changed, which can be useful in certain circumstances. Overall, it feels that losing type checking for a faster and more flexible runtime is a better choice for OIT's usage, (mainly running tests and small dev scripts as far as I can tell).