How Deno Executes TypeScript Without Extra Tooling

Useful answer: run TypeScript instantly

If you want to execute a TypeScript file without installing a separate compiler, Deno does it for you. The runtime ships a Rust‑based swc compiler that transpiles your .ts or .tsx source to JavaScript, feeds the result to V8, and optionally runs type‑checking. No tsc, babel, or webpack configuration is required to get started.

How it works: a worked example

Create a file named hello.ts with the following content:

// hello.ts
console.log('Hello from Deno at', new Date().toISOString());

Run it from a terminal where Deno is installed:

# Run the file (no type‑checking by default)
$ deno run hello.ts
Hello from Deno at 2026-10-18T17:25:46.291Z

What happens under the hood:

1. Deno reads hello.ts.
2. The internal SWC compiler parses the TypeScript syntax, transforms it to plain JavaScript (ES2022 target by default), and produces an in‑memory module.
3. V8 executes that JavaScript.
4. Because we invoked deno run without --check, no type‑checking pass is performed, so the start‑up is fast.

Now introduce a type error to see the optional checking step:

// hello.ts with error
const x: number = 'oops'; // Type 'string' is not assignable to type 'number'.
console.log(x);

Running the file still succeeds because type‑checking is skipped:

$ deno run hello.ts
# prints: oops (runtime coercion happens, but the program runs)

To catch the error before execution, ask Deno to type‑check:

$ deno check hello.ts
error: TS2322: Type '"oops"' is not assignable to type 'number'.
    const x: number = 'oops';
                ~~~~~~

The check uses the same SWC type‑checker that the runtime would use if you passed --check to deno run. No JavaScript is emitted; only diagnostics are reported.

Configuration: when you need it

Deno works out of the box, but you can adjust compiler behaviour with a deno.json or deno.jsonc file placed in the project root. A minimal example that sets the target to ES2020 and enables strict mode:

{
  "compilerOptions": {
    "target": "ES2020",
    "strict": true,
    "lib": ["DOM"]
  }
}

If the file is absent, Deno assumes ES2022 target, includes the DOM library, and enables strict mode. Import maps for aliasing remote modules go in the same file under the importMap key.

Limits and common mistakes

Limits

• Large codebases: Deno’s type‑checker runs the whole module graph each time you invoke deno check or deno run --check. For very large projects this can be slower than incremental tsc --watch.
• Unsupported TS features: Features that rely on custom Babel/plugins or TypeScript emit helpers—such as emitDecoratorMetadata or custom transformers—are not available because Deno does not plug into the TypeScript emitter pipeline.
• Declaration file generation: deno emit --declaration produces .d.ts files, but the output may differ from tsc --declaration for advanced conditional types or module augmentation. Library authors should still verify the generated declarations.

Common mistakes

• Assuming deno run type‑checks. It does not; add --check or run deno check separately.
• Committing the cache directory ($DENO_DIR or ~/.cache/deno) to version control. The cache is safe to ignore; set DENO_DIR to a local folder in CI to keep your home directory clean.
• Expecting a tsconfig.json to be read automatically. Deno ignores it unless you explicitly pass -c / --config (deprecated) or migrate its options into deno.json.
• Mixing Node‑style resolution (require, node_modules) with Deno URLs in the same project without an import map. This leads to “module not found” errors; use an import map to redirect bare specifiers to CDN URLs if needed.

Practical verification steps

1. Confirm you have a recent Deno version (≥ 1.40 for stable SWC‑based TS): deno --version.
2. Create a test.ts file with a deliberate type error, run deno run test.ts (should execute), then run deno check test.ts (should fail with a diagnostic).
3. Inspect the module cache: deno info shows the location; deno cache --reload forces a fresh fetch of remote modules.
4. For library authors, compare declaration output: deno emit --declaration lib.ts vs tsc --declaration lib.ts and check the generated .d.ts files for differences.

Following these steps lets you take advantage of Deno’s zero‑setup TypeScript execution while being aware of where the behaviour diverges from the traditional tsc workflow.