Setting Up TypeScript

TypeScript code needs to be compiled to JavaScript before it runs. This lesson covers installing the compiler, configuring it, and running it against a real file.

Installing the compiler

npm install --save-dev typescript

Installing it as a project dependency (rather than globally) keeps the TypeScript version pinned per-project, so everyone working on the codebase compiles with the same version.

Writing and compiling a file

// greet.ts
function greet(name: string): string {
  return `Hello, ${name}!`;
}

console.log(greet("Ada"));

npx tsc greet.ts

This produces greet.js — plain JavaScript, types stripped — which you then run with node greet.js, exactly like any other JavaScript file.

tsconfig.json

Real projects configure the compiler with a tsconfig.json file instead of passing flags on the command line every time:

npx tsc --init

That generates a tsconfig.json with sensible defaults, commented out. A few of the settings worth understanding from day one:

{
  "compilerOptions": {
    "target": "ES2020",
    "module": "ESNext",
    "strict": true,
    "outDir": "./dist",
    "rootDir": "./src"
  }
}

• target — which JavaScript version the compiled output uses (older targets add more compatibility shims for newer syntax).
• strict — turns on TypeScript's full set of strict type-checking rules at once, including disallowing implicit any and requiring null checks. Leave this on; it's the single setting most responsible for TypeScript actually catching bugs rather than just decorating your code with annotations that don't do much.
• outDir/rootDir — where compiled .js output goes, versus where your .ts source files live.

With a tsconfig.json in place, running tsc with no arguments compiles the whole project according to that configuration.

Checking types without emitting files

npx tsc --noEmit

This runs the type checker and reports errors without writing any .js output — useful as a fast "does this compile cleanly" check, often wired into CI or a pre-commit hook, separate from whatever actually bundles the code for production (tools like Vite, esbuild, or webpack typically handle the JS output themselves and treat tsc purely as the type checker).

In practice: frameworks handle this for you

Most real projects don't call tsc directly for building — a framework's own tooling (Next.js, Vite, etc.) compiles TypeScript as part of its build process, and tsc --noEmit is run separately just for type checking. Still, understanding what's happening underneath — annotate, compile, strip types, run as JavaScript — makes every layer built on top of it easier to reason about.

With the compiler running, the next lessons cover the type system itself, starting with the basic types TypeScript understands.