TypeScript execution environment and REPL for node.js, with source map support
The ts-node npm package is a TypeScript execution engine and REPL for Node.js. It allows developers to run TypeScript files directly without precompiling them to JavaScript. This is particularly useful for development purposes where you can execute scripts or run a REPL environment without an additional build step.
Execute TypeScript files
Run a TypeScript file directly from the command line without prior compilation.
ts-node script.tsREPL
Start a TypeScript REPL (Read-Eval-Print Loop) to execute TypeScript code interactively.
ts-nodeTranspile Only Mode
Run TypeScript files without type checking for faster execution, suitable for development.
ts-node --transpile-only script.tsType Checking
Enable type checking when running a TypeScript file, ensuring that the code adheres to the defined types.
ts-node --type-check script.tsIntegration with Testing Frameworks
Use ts-node to run TypeScript tests with Mocha or other Node.js testing frameworks.
mocha --require ts-node/register tests/**/*.spec.tsesbuild-register uses the esbuild bundler to transpile TypeScript and JavaScript files on the fly. It is known for its speed and efficiency compared to ts-node, which can be slower due to its full type checking.
babel-node is a part of the Babel toolchain that allows running TypeScript and modern JavaScript directly. It is similar to ts-node but uses Babel for transpilation, which can be more configurable and supports a wider range of JavaScript features and experimental syntax.
sucrase-node is a development tool that allows super-fast development builds. It is similar to ts-node but focuses on speed by avoiding full type checking and supporting a subset of TypeScript features.
swc-node is a TypeScript/JavaScript compiler that uses SWC, a super-fast compiler written in Rust. It is designed to be a faster alternative to ts-node, especially for larger codebases.
TypeScript execution and REPL for node.js, with source map and native ESM support.
The latest documentation can also be found on our website: https://typestrong.org/ts-node
ts-node is a TypeScript execution engine and REPL for Node.js.
It JIT transforms TypeScript into JavaScript, enabling you to directly execute TypeScript on Node.js without precompiling. This is accomplished by hooking node's module loading APIs, enabling it to be used seamlessly alongside other Node.js tools and libraries.
tsconfig.json parsing
# Locally in your project.
npm install -D typescript
npm install -D ts-node
# Or globally with TypeScript.
npm install -g typescript
npm install -g ts-node
# Depending on configuration, you may also need these
npm install -D tslib @types/node
Tip: Installing modules locally allows you to control and share the versions through package.json. ts-node will always resolve the compiler from cwd before checking relative to its own installation.
# Execute a script as `node` + `tsc`.
ts-node script.ts
# Starts a TypeScript REPL.
ts-node
# Execute code with TypeScript.
ts-node -e 'console.log("Hello, world!")'
# Execute, and print, code with TypeScript.
ts-node -p -e '"Hello, world!"'
# Pipe scripts to execute with TypeScript.
echo 'console.log("Hello, world!")' | ts-node
# Equivalent to ts-node --transpileOnly
ts-node-transpile-only script.ts
# Equivalent to ts-node --cwdMode
ts-node-cwd script.ts
# Equivalent to ts-node --esm
ts-node-esm script.ts
#!/usr/bin/env ts-node
console.log("Hello, world!")
Passing options via shebang requires the env -S flag, which is available on recent versions of env. (compatibility)
#!/usr/bin/env -S ts-node --files
// This shebang works on Mac and Linux with newer versions of env
// Technically, Mac allows omitting `-S`, but Linux requires it
To write scripts with maximum portability, specify all options in your tsconfig.json and omit them from the shebang.
#!/usr/bin/env ts-node
// This shebang works everywhere
To test your version of env for compatibility:
# Note that these unusual quotes are necessary
/usr/bin/env --debug '-S echo foo bar'
You can require ts-node and register the loader for future requires by using require('ts-node').register({ /* options */ }). You can also use file shortcuts - node -r ts-node/register or node -r ts-node/register/transpile-only - depending on your preferences.
Note: If you need to use advanced node.js CLI arguments (e.g. --inspect), use them with node -r ts-node/register instead of ts-node's CLI.
ts-node exports a create() function that can be used to initialize a TypeScript compiler that isn't registered to require.extensions, and it uses the same code as register.
ts-node supports a variety of options which can be specified via tsconfig.json, as CLI flags, as environment variables, or programmatically.
For a complete list, see Options.
ts-node CLI flags must come before the entrypoint script. For example:
$ ts-node --project tsconfig-dev.json say-hello.ts Ronald
Hello, Ronald!
ts-node automatically finds and loads tsconfig.json. Most ts-node options can be specified in a "ts-node" object using their programmatic, camelCase names. We recommend this because it works even when you cannot pass CLI flags, such as node --require ts-node/register and when using shebangs.
Use --skipProject to skip loading the tsconfig.json. Use --project to explicitly specify the path to a tsconfig.json.
When searching, it is resolved using the same search behavior as tsc. By default, this search is performed relative to the entrypoint script. In --cwdMode or if no entrypoint is specified -- for example when using the REPL -- the search is performed relative to --cwd / process.cwd().
You can use this sample configuration as a starting point:
{
// This is an alias to @tsconfig/node12: https://github.com/tsconfig/bases
"extends": "ts-node/node12/tsconfig.json",
// Most ts-node options can be specified here using their programmatic names.
"ts-node": {
// It is faster to skip typechecking.
// Remove if you want ts-node to do typechecking.
"transpileOnly": true,
"files": true,
"compilerOptions": {
// compilerOptions specified here will override those declared below,
// but *only* in ts-node. Useful if you want ts-node and tsc to use
// different options with a single tsconfig.json.
}
},
"compilerOptions": {
// typescript options here
}
}
Our bundled JSON schema lists all compatible options.
@tsconfig/bases maintains recommended configurations for several node versions. As a convenience, these are bundled with ts-node.
{
"extends": "ts-node/node16/tsconfig.json",
// Or install directly with `npm i -D @tsconfig/node16`
"extends": "@tsconfig/node16/tsconfig.json",
}
If no tsconfig.json is loaded from disk, ts-node will use the newest recommended defaults from
@tsconfig/bases compatible with your node and typescript versions.
With the latest node and typescript, this is @tsconfig/node16.
Older versions of typescript are incompatible with @tsconfig/node16. In those cases we will use an older default configuration.
When in doubt, ts-node --showConfig will log the configuration being used, and ts-node -vv will log node and typescript versions.
node flagsnode flags must be passed directly to node; they cannot be passed to the ts-node binary nor can they be specified in tsconfig.json
We recommend using the NODE_OPTIONS environment variable to pass options to node.
NODE_OPTIONS='--trace-deprecation --abort-on-uncaught-exception' ts-node ./index.ts
Alternatively, you can invoke node directly and install ts-node via --require/-r
node --trace-deprecation --abort-on-uncaught-exception -r ts-node/register ./index.ts
ts-node supports --print (-p), --eval (-e), --require (-r) and --interactive (-i) similar to the node.js CLI options.
All command-line flags support both --camelCase and --hyphen-case.
Environment variables, where available, are in ALL_CAPS
-h, --help Prints the help text-v, --version Prints the version. -vv prints node and typescript compiler versions, too-e, --eval Evaluate code-p, --print Print result of --eval-i, --interactive Opens the REPL even if stdin does not appear to be a terminal--esm Bootstrap with the ESM loader, enabling full ESM support-P, --project [path] Path to TypeScript JSON project file TS_NODE_PROJECT--skipProject Skip project config resolution and loading false TS_NODE_SKIP_PROJECT-c, --cwdMode Resolve config relative to the current directory instead of the directory of the entrypoint script-O, --compilerOptions [opts] JSON object to merge with compiler options TS_NODE_COMPILER_OPTIONS--showConfig Print resolved tsconfig.json, including ts-node options, and exit-T, --transpileOnly Use TypeScript's faster transpileModule false TS_NODE_TRANSPILE_ONLY--typeCheck Opposite of --transpileOnly trueTS_NODE_TYPE_CHECK-H, --compilerHost Use TypeScript's compiler host API false TS_NODE_COMPILER_HOST--files Load files, include and exclude from tsconfig.json on startup false TS_NODE_FILES-D, --ignoreDiagnostics [code] Ignore TypeScript warnings by diagnostic code TS_NODE_IGNORE_DIAGNOSTICS-I, --ignore [pattern] Override the path patterns to skip compilation /node_modules/ TS_NODE_IGNORE--skipIgnore Skip ignore checks false TS_NODE_SKIP_IGNORE-C, --compiler [name] Specify a custom TypeScript compiler typescript TS_NODE_COMPILER--swc Transpile with swc. Implies --transpileOnly false--transpiler [name] Specify a third-party, non-typechecking transpiler--preferTsExts Re-order file extensions so that TypeScript imports are preferred false TS_NODE_PREFER_TS_EXTS--logError Logs TypeScript errors to stderr instead of throwing exceptions false TS_NODE_LOG_ERROR--pretty Use pretty diagnostic formatter false TS_NODE_PRETTYTS_NODE_DEBUG Enable debug logging-r, --require [path] Require a node module before execution--cwd Behave as if invoked in this working directory process.cwd()TS_NODE_CWD--emit Emit output files into .ts-node directory false TS_NODE_EMIT--scope Scope compiler to files within scopeDir. Anything outside this directory is ignored. false TS_NODE_SCOPE--scopeDir Directory within which compiler is limited when scope is enabled. tsconfig.json "rootDir" if specified, directory containing tsconfig.json, or cwd if no tsconfig.json is loaded.TS_NODE_SCOPE_DIRmoduleTypes Override the module type of certain files, ignoring the package.json "type" field. See Module type overrides for details.package.json "type" and tsconfig.json "module" tsconfig.json or API.TS_NODE_HISTORY Path to history file for REPL ~/.ts_node_repl_history--noExperimentalReplAwait Disable top-level await in REPL. Equivalent to node's --no-experimental-repl-awaitTS_NODE_EXPERIMENTAL_REPL_AWAIT set false to disableexperimentalResolverFeatures Enable experimental features that re-map imports and require calls to support: baseUrl, paths, rootDirs, .js to .ts file extension mappings, outDir to rootDir mappings for composite projects and monorepos. For details, see #1514falsetsconfig.json or API.The API includes additional options not shown here.
TypeScript is almost always written using modern import syntax, but it is also transformed before being executed by the underlying runtime. You can choose to either transform to CommonJS or to preserve the native import syntax, using node's native ESM support. Configuration is different for each.
Here is a brief comparison of the two.
| CommonJS | Native ECMAScript modules |
|---|---|
Write native import syntax | Write native import syntax |
Transforms import into require() | Does not transform import |
| Node executes scripts using the classic CommonJS loader | Node executes scripts using the new ESM loader |
Use any of:ts-nodenode -r ts-node/registerNODE_OPTIONS="ts-node/register" noderequire('ts-node').register({/* options */}) | Use any of:ts-node --esmts-node-esmSet "esm": true in tsconfig.jsonnode --loader ts-node/esmNODE_OPTIONS="--loader ts-node/esm" node |
Transforming to CommonJS is typically simpler and more widely supported because it is older. You must remove "type": "module" from package.json and set "module": "CommonJS" in tsconfig.json.
{
// This can be omitted; commonjs is the default
"type": "commonjs"
}
{
"compilerOptions": {
"module": "CommonJS"
}
}
If you must keep "module": "ESNext" for tsc, webpack, or another build tool, you can set an override for ts-node.
{
"compilerOptions": {
"module": "ESNext"
},
"ts-node": {
"compilerOptions": {
"module": "CommonJS"
}
}
}
Node's ESM loader hooks are experimental and subject to change. ts-node's ESM support is as stable as possible, but it relies on APIs which node can and will break in new versions of node. Thus it is not recommended for production.
For complete usage, limitations, and to provide feedback, see #1007.
You must set "type": "module" in package.json and "module": "ESNext" in tsconfig.json.
{
"type": "module"
}
{
"compilerOptions": {
"module": "ESNext" // or ES2015, ES2020
},
"ts-node": {
// Tell ts-node CLI to install the --loader automatically, explained below
"esm": true
}
}
You must also ensure node is passed --loader. The ts-node CLI will do this automatically with our esm option.
Note:
--esmmust spawn a child process to pass it--loader. This may change if node adds the ability to install loader hooks into the current process.
# pass the flag
ts-node --esm
# Use the convenience binary
ts-node-esm
# or add `"esm": true` to your tsconfig.json to make it automatic
ts-node
If you are not using our CLI, pass the loader flag to node.
node --loader ts-node/esm ./index.ts
# Or via environment variable
NODE_OPTIONS="--loader ts-node/esm" node ./index.ts
ts-node uses sensible default configurations to reduce boilerplate while still respecting tsconfig.json if you
have one. If you are unsure which configuration is used, you can log it with ts-node --showConfig. This is similar to
tsc --showConfig but includes "ts-node" options as well.
ts-node also respects your locally-installed typescript version, but global installations fallback to the globally-installed
typescript. If you are unsure which versions are used, ts-node -vv will log them.
$ ts-node -vv
ts-node v10.0.0
node v16.1.0
compiler v4.2.2
$ ts-node --showConfig
{
"compilerOptions": {
"target": "es6",
"lib": [
"es6",
"dom"
],
"rootDir": "./src",
"outDir": "./.ts-node",
"module": "commonjs",
"moduleResolution": "node",
"strict": true,
"declaration": false,
"sourceMap": true,
"inlineSources": true,
"types": [
"node"
],
"stripInternal": true,
"incremental": true,
"skipLibCheck": true,
"importsNotUsedAsValues": "error",
"inlineSourceMap": false,
"noEmit": false
},
"ts-node": {
"cwd": "/d/project",
"projectSearchDir": "/d/project",
"require": [],
"project": "/d/project/tsconfig.json"
}
}
It is important to differentiate between errors from ts-node, errors from the TypeScript compiler, and errors from node. It is also important to understand when errors are caused by a type error in your code, a bug in your code, or a flaw in your configuration.
TSErrorType errors from the compiler are thrown as a TSError. These are the same as errors you get from tsc.
SyntaxErrorAny error that is not a TSError is from node.js (e.g. SyntaxError), and cannot be fixed by TypeScript or ts-node. These are bugs in your code or configuration.
Your version of node may not support all JavaScript syntax supported by TypeScript. The compiler must transform this syntax via "downleveling," which is controlled by
the tsconfig "target" option. Otherwise your code will compile fine, but node will throw a SyntaxError.
For example, node 12 does not understand the ?. optional chaining operator. If you use "target": "esnext", then the following TypeScript syntax:
const bar: string | undefined = foo?.bar;
will compile into this JavaScript:
const a = foo?.bar;
When you try to run this code, node 12 will throw a SyntaxError. To fix this, you must switch to "target": "es2019" or lower so TypeScript transforms ?. into something node can understand.
These tricks will make ts-node faster.
It is often better to use tsc --noEmit to typecheck once before your tests run or as a lint step. In these cases, ts-node can skip typechecking.
transpileOnly to skip typecheckingswc integration
require() which may trigger repeated typechecking; prefer import--files; one may be faster depending on your projecttsc --showConfig; make sure all executed files are includedskipLibChecktypes array to avoid loading unnecessary @typests-node works by registering hooks for .ts, .tsx, .js, and/or .jsx extensions.
Vanilla node loads .js by reading code from disk and executing it. Our hook runs in the middle, transforming code from TypeScript to JavaScript and passing the result to node for execution. This transformation will respect your tsconfig.json as if you had compiled via tsc.
.js and .jsx are only transformed when allowJs is enabled.
.tsx and .jsx are only transformed when jsx is enabled.
Warning: if a file is ignored or its file extension is not registered, node will either fail to resolve the file or will attempt to execute it as JavaScript without any transformation. This may cause syntax errors or other failures, because node does not understand TypeScript type syntax nor bleeding-edge ECMAScript features.
Warning: When ts-node is used with
allowJs, all non-ignored JavaScript files are transformed using the TypeScript compiler.
node_modulesBy default, ts-node avoids compiling files in /node_modules/ for three reasons:
If you need to import uncompiled TypeScript in node_modules, use --skipIgnore or TS_NODE_SKIP_IGNORE to bypass this restriction.
If a compiled JavaScript file with the same name as a TypeScript file already exists, the TypeScript file will be ignored. ts-node will import the pre-compiled JavaScript.
To force ts-node to import the TypeScript source, not the precompiled JavaScript, use --preferTsExts.
You can use ts-node together with tsconfig-paths to load modules according to the paths section in tsconfig.json.
{
"ts-node": {
// Do not forget to `npm i -D tsconfig-paths`
"require": ["tsconfig-paths/register"]
}
}
The official TypeScript Handbook explains the intended purpose for "paths" in "Additional module resolution flags".
The TypeScript compiler has a set of additional flags to inform the compiler of transformations that are expected to happen to the sources to generate the final output.
It is important to note that the compiler will not perform any of these transformations; it just uses these pieces of information to guide the process of resolving a module import to its definition file.
This means "paths" are intended to describe mappings that the build tool or runtime already performs, not to tell the build tool or
runtime how to resolve modules. In other words, they intend us to write our imports in a way node already understands. For this reason, ts-node does not modify node's module resolution behavior to implement "paths" mappings.
ts-node does not use files, include or exclude, by default. This is because a large majority projects do not use all of the files in a project directory (e.g. Gulpfile.ts, runtime vs tests) and parsing every file for types slows startup time. Instead, ts-node starts with the script file (e.g. ts-node index.ts) and TypeScript resolves dependencies based on imports and references.
For global definitions, you can use the typeRoots compiler option. This requires that your type definitions be structured as type packages (not loose TypeScript definition files). More details on how this works can be found in the TypeScript Handbook.
Example tsconfig.json:
{
"compilerOptions": {
"typeRoots" : ["./node_modules/@types", "./typings"]
}
}
Example project structure:
<project_root>/
-- tsconfig.json
-- typings/
-- <module_name>/
-- index.d.ts
Example module declaration file:
declare module '<module_name>' {
// module definitions go here
}
For module definitions, you can use paths:
{
"compilerOptions": {
"baseUrl": ".",
"paths": {
"custom-module-type": ["types/custom-module-type"]
}
}
}
An alternative approach for definitions of third-party libraries are triple-slash directives. This may be helpful if you prefer not to change your TypeScript compilerOptions or structure your custom type definitions when using typeRoots. Below is an example of the triple-slash directive as a relative path within your project:
/// <reference path="./types/untyped_js_lib" />
import {Greeter} from "untyped_js_lib"
const g = new Greeter();
g.sayHello();
Tip: If you must use files, include, or exclude, enable --files flags or set TS_NODE_FILES=true.
Some projects require a patched typescript compiler which adds additional features. For example, ttypescript and ts-patch
add the ability to configure custom transformers. These are drop-in replacements for the vanilla typescript module and
implement the same API.
For example, to use ttypescript and ts-transformer-keys, add this to your tsconfig.json:
{
"ts-node": {
// This can be omitted when using ts-patch
"compiler": "ttypescript"
},
"compilerOptions": {
// plugin configuration is the same for both ts-patch and ttypescript
"plugins": [
{ "transform": "ts-transformer-keys/transformer" }
]
}
}
In transpile-only mode, we skip typechecking to speed up execution time. You can go a step further and use a
third-party transpiler to transform TypeScript into JavaScript even faster. You will still benefit from
ts-node's automatic tsconfig.json discovery, sourcemap support, and global ts-node CLI. Integrations
can automatically derive an appropriate configuration from your existing tsconfig.json which simplifies project
boilerplate.
What is the difference between a compiler and a transpiler?
For our purposes, a compiler implements TypeScript's API and can perform typechecking. A third-party transpiler does not. Both transform TypeScript into JavaScript.
swc support is built-in via the --swc flag or "swc": true tsconfig option.
swc is a TypeScript-compatible transpiler implemented in Rust. This makes it an order of magnitude faster than vanilla transpileOnly.
To use it, first install @swc/core or @swc/wasm. If using importHelpers, also install @swc/helpers. If target is less than "es2015" and using either async/await or generator functions, also install regenerator-runtime.
npm i -D @swc/core @swc/helpers regenerator-runtime
Then add the following to your tsconfig.json.
{
"ts-node": {
"swc": true
}
}
swcuses@swc/helpersinstead oftslib. If you have enabledimportHelpers, you must also install@swc/helpers.
The transpiler option allows using third-party transpiler integrations with ts-node. transpiler must be given the
name of a module which can be require()d. The built-in swc integration is exposed as ts-node/transpilers/swc.
For example, to use a hypothetical "speedy-ts-compiler", first install it into your project: npm install speedy-ts-compiler
Then add the following to your tsconfig:
{
"ts-node": {
"transpileOnly": true,
"transpiler": "speedy-ts-compiler"
}
}
To write your own transpiler integration, check our API docs.
Integrations are require()d by ts-node, so they can be published to npm for convenience. The module must export a create function described by our
TranspilerModule interface. create is invoked by ts-node
at startup to create the transpiler. The transpiler is used repeatedly to transform TypeScript into JavaScript.
When deciding between CommonJS and native ECMAScript modules, ts-node defaults to matching vanilla node and tsc
behavior. This means TypeScript files are transformed according to your tsconfig.json "module" option and executed
according to node's rules for the package.json "type" field.
In some projects you may need to override this behavior for some files. For example, in a webpack
project, you may have package.json configured with "type": "module" and tsconfig.json with
"module": "esnext". However, webpack uses our CommonJS hook to execute your webpack.config.ts,
so you need to force your webpack config and any supporting scripts to execute as CommonJS.
In these situations, our moduleTypes option lets you override certain files, forcing execution as
CommonJS or ESM. Node supports similar overriding via .cjs and .mjs file extensions, but .ts files cannot use them.
moduleTypes achieves the same effect, and also overrides your tsconfig.json "module" config appropriately.
The following example tells ts-node to execute a webpack config as CommonJS:
{
"ts-node": {
"transpileOnly": true,
"moduleTypes": {
"webpack.config.ts": "cjs",
// Globs are also supported with the same behavior as tsconfig "include"
"webpack-config-scripts/**/*": "cjs"
}
},
"compilerOptions": {
"module": "es2020",
"target": "es2020"
}
}
Each key is a glob pattern with the same syntax as tsconfig's "include" array.
When multiple patterns match the same file, the last pattern takes precedence.
cjs overrides matches files to compile and execute as CommonJS.esm overrides matches files to compile and execute as native ECMAScript modules.package resets either of the above to default behavior, which obeys package.json "type" and tsconfig.json "module" options.Files with an overridden module type are transformed with the same limitations as isolatedModules. This will only affect rare cases such as using const enums with preserveConstEnums disabled.
This feature is meant to facilitate scenarios where normal compilerOptions and package.json configuration is not possible. For example, a webpack.config.ts cannot be given its own package.json to override "type". Wherever possible you should favor using traditional package.json and tsconfig.json configurations.
TypeScript Node compiles source code via require(), watching files and code reloads are out of scope for the project. If you want to restart the ts-node process on file change, existing node.js tools such as nodemon, onchange and node-dev work.
There's also ts-node-dev, a modified version of node-dev using ts-node for compilation that will restart the process on file change.
Assuming you are configuring AVA via your package.json, add one of the following configurations.
Use this configuration if your package.json does not have "type": "module".
{
"ava": {
"extensions": [
"ts"
],
"require": [
"ts-node/register"
]
}
}
This configuration is necessary if your package.json has "type": "module".
{
"ava": {
"extensions": {
"ts": "module"
},
"nonSemVerExperiments": {
"configurableModuleFormat": true
},
"nodeArguments": [
"--loader=ts-node/esm"
]
}
}
ts-node support is built-in to gulp.
# Create a `gulpfile.ts` and run `gulp`.
gulp
See also: https://gulpjs.com/docs/en/getting-started/javascript-and-gulpfiles#transpilation
Create a new Node.js configuration and add -r ts-node/register to "Node parameters."
Note: If you are using the --project <tsconfig.json> command line argument as per the Configuration Options, and want to apply this same behavior when launching in IntelliJ, specify under "Environment Variables": TS_NODE_PROJECT=<tsconfig.json>.
mocha --require ts-node/register --extensions ts,tsx --watch --watch-files src 'tests/**/*.{ts,tsx}' [...args]
Or specify options via your mocha config file.
{
// Specify "require" for CommonJS
"require": "ts-node/register",
// Specify "loader" for native ESM
"loader": "ts-node/esm",
"extensions": ["ts", "tsx"],
"spec": [
"tests/**/*.spec.*"
],
"watch-files": [
"src"
]
}
See also: https://mochajs.org/#configuring-mocha-nodejs
mocha --require ts-node/register --watch-extensions ts,tsx "test/**/*.{ts,tsx}" [...args]
Note: --watch-extensions is only used in --watch mode.
ts-node node_modules/tape/bin/tape [...args]
Create a new Node.js debug configuration, add -r ts-node/register to node args and move the program to the args list (so VS Code doesn't look for outFiles).
{
"configurations": [{
"type": "node",
"request": "launch",
"name": "Launch Program",
"runtimeArgs": [
"-r",
"ts-node/register"
],
"args": [
"${workspaceFolder}/src/index.ts"
]
}],
}
Note: If you are using the --project <tsconfig.json> command line argument as per the Configuration Options, and want to apply this same behavior when launching in VS Code, add an "env" key into the launch configuration: "env": { "TS_NODE_PROJECT": "<tsconfig.json>" }.
In many cases, setting NODE_OPTIONS will enable ts-node within other node tools, child processes, and worker threads.
NODE_OPTIONS="-r ts-node/register"
Or, if you require native ESM support:
NODE_OPTIONS="--loader ts-node/esm"
This tells any node processes which receive this environment variable to install ts-node's hooks before executing other code.
ts-node is licensed under the MIT license. MIT
ts-node includes source code from Node.js which is licensed under the MIT license. Node.js license information
ts-node includes source code from the TypeScript compiler which is licensed under the Apache License 2.0. TypeScript license information
FAQs
TypeScript execution environment and REPL for node.js, with source map support
We found that ts-node demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 2 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Research
An advanced npm supply chain attack is leveraging Ethereum smart contracts for decentralized, persistent malware control, evading traditional defenses.
Security News
Research
Attackers are impersonating Sindre Sorhus on npm with a fake 'chalk-node' package containing a malicious backdoor to compromise developers' projects.
Security News
The npm package for the LottieFiles Player web component was hit with a supply chain attack after a software engineer's npmjs credentials were compromised.