TypeScript has become the dominant language for serious JavaScript development, and 2026 marks a turning point: TypeScript 6.0 ships with strict mode enabled by default, ES module resolution out of the box, and Node.js v22.18.0 now runs TypeScript files natively without a separate compilation step. Whether you are a complete beginner who has never written a typed variable or an intermediate JavaScript developer ready to level up, this typescript tutorial walks you through every concept you need – from installation to a production-ready REST API with CI/CD. By the end you will have a working project on GitHub, a deployment pipeline, and the mental models to tackle any TypeScript codebase in the wild.

This guide is structured as a step-by-step typescript tutorial 2026, meaning every section builds directly on the previous one. You will install the compiler, understand the type system, write interfaces and generics, build a complete Express REST API, test it with Vitest, and ship it through GitHub Actions. Intermediate developers can jump to specific steps using the headings below. Beginners are encouraged to follow every step in order. All code samples have been verified against TypeScript 6.0 and Node.js v22.

Prerequisites and Environment Setup

Before you write a single line of typed code, your development environment must be in order. A mismatched Node version is the single most common reason beginners run into cryptic errors on their first day. The table below lists every tool referenced in this typescript guide, the version required, and why it matters. All versions listed are current as of April 2026.

Tool	Minimum Version	Recommended Version	Purpose
Node.js	20.0.0	22.18.0+	Runtime; v22.18.0+ supports native –experimental-strip-types for running .ts files directly
npm	9.0.0	10.9.0+	Package management; ships with Node.js
TypeScript	5.8.0	6.0.x	Compiler; 6.0 enables strict mode by default and ES module resolution
VS Code	1.88.0	Latest stable	Editor; built-in TypeScript language service; TS 7.0 preview available as extension
Git	2.40.0	2.47.0+	Version control; required for CI/CD step
Vite	5.0.0	6.2.0+	Build tool for frontend TypeScript projects; natively understands .ts files
Vitest	1.0.0	3.1.0+	Unit testing framework designed for TypeScript and Vite projects

Install Node.js from the official site at nodejs.org. Use the LTS release (22.x) unless you have a specific reason to stay on 20.x. Once Node is installed, verify both Node and npm are available in your terminal:

node --version
# v22.18.0
npm --version
# 10.9.2

You will also want the ESLint extension and the official TypeScript + JavaScript extension installed in VS Code. These give you inline type errors, auto-imports, and hover documentation without leaving your editor. If you want to preview the Go-based TypeScript 7.0 language service – which offers near-instant cold start times compared to the JS-based server – search for “TypeScript Nightly” in the VS Code extensions marketplace and enable it workspace-by-workspace rather than globally, so it does not affect existing projects.

A word on package managers: this guide uses npm throughout for maximum compatibility. If your team uses pnpm or Yarn Berry, every npm install command translates directly – just substitute the equivalent pnpm or yarn syntax. The TypeScript compiler itself is indifferent to your package manager choice.

Finally, make sure your terminal is configured to use UTF-8 encoding and that your PATH includes the local node_modules/.bin directory or that you use npx to run locally installed tools. This avoids the common confusion where a globally installed TypeScript version shadows the project-local one, causing version mismatches mid-project. TypeScript downloads exceed 30 million weekly on npm as of 2026, meaning the ecosystem of compatible tools and type definitions has never been richer.

Step 1 – Installing TypeScript 6.0 and Configuring Your Project

Every serious TypeScript project starts with a properly structured tsconfig.json. Many beginners skip this step or copy a config from Stack Overflow without understanding what it does, then spend hours debugging errors that the config itself is causing. This section of our typescript tutorial for beginners gives you a production-quality starting config and explains each option.

Create a new project directory and initialize it:

mkdir typescript-tutorial-2026
cd typescript-tutorial-2026
npm init -y
npm install --save-dev typescript@6 @types/node

Next, generate a tsconfig.json with the TypeScript CLI:

npx tsc --init

Replace the generated file with this production-ready configuration that reflects TypeScript 6.0 defaults:

{
 "compilerOptions": {
 "target": "ES2022",
 "module": "ESNext",
 "moduleResolution": "bundler",
 "lib": ["ES2022"],
 "outDir": "./dist",
 "rootDir": "./src",
 "strict": true,
 "noUncheckedIndexedAccess": true,
 "exactOptionalPropertyTypes": true,
 "noImplicitOverride": true,
 "declaration": true,
 "declarationMap": true,
 "sourceMap": true,
 "esModuleInterop": true,
 "forceConsistentCasingInFileNames": true,
 "skipLibCheck": false
 },
 "include": ["src/**/*"],
 "exclude": ["node_modules", "dist", "**/*.test.ts"]
}

The table below explains each critical compiler option so you understand what you are opting into rather than treating the config as a magic incantation:

Option	TS 6.0 Default	Description
strict	true	Enables all strict type-checking flags. New in TS 6.0: this is now true by default on fresh inits.
moduleResolution	bundler	Resolves modules the way modern bundlers (Vite, esbuild, webpack 5) do. Replaces the older “node16” setting for most projects.
noUncheckedIndexedAccess	false	Array and object index access returns T | undefined instead of T. Prevents a huge class of runtime errors.
exactOptionalPropertyTypes	false	Distinguishes between a property being absent and a property explicitly set to undefined.
target	ES2022	Compilation output target. ES2022 is safe for all modern runtimes including Node 18+.
declaration	false	Emits .d.ts files alongside JS output. Essential for libraries published to npm.
sourceMap	false	Generates .js.map files so debuggers and error trackers can map back to original TypeScript source.
skipLibCheck	false	Set to true only as a last resort when third-party type definitions contain errors you cannot fix.

Create your source directory and a first file to confirm the setup works:

mkdir src
echo 'const greeting: string = "TypeScript 6.0 is ready!"; console.log(greeting);' > src/index.ts
npx tsc
node dist/index.js
# TypeScript 6.0 is ready!

Add a build and dev script to package.json for convenience. Set "type": "module" since TypeScript 6.0 now defaults to ES module output:

{
 "type": "module",
 "scripts": {
 "build": "tsc",
 "dev": "node --experimental-strip-types src/index.ts",
 "typecheck": "tsc --noEmit"
 }
}

The dev script takes advantage of Node.js v22.18.0’s native TypeScript support. The --experimental-strip-types flag tells Node to remove type annotations at runtime without running the full TypeScript compiler, giving you a fast feedback loop during development. Note that this does not perform type checking – run npm run typecheck separately to catch type errors before committing. This two-step workflow (fast runtime iteration + explicit type check) is the standard pattern in 2026.

TS 6.0 also deprecates import assertions (the assert { type: "json" } syntax) in favour of import attributes (with { type: "json" }). If your project uses import assertions, migrate them now to avoid deprecation warnings. Additionally, older compilation targets like ES3 and ES5 are deprecated in TS 6.0 – set target to ES2018 or higher in all new projects.

Step 2 – Understanding TypeScript Type System Fundamentals

The TypeScript type system is not a simple layer of documentation on top of JavaScript – it is a full structural type system with inference, narrowing, and assignability rules that define what code is valid. This section of the learn typescript journey covers the primitives, literal types, union types, intersection types, and the crucial concept of type narrowing that powers safe runtime code.

Start with the primitive types. TypeScript recognises string, number, boolean, null, undefined, symbol, and bigint as primitives. With strict: true, null and undefined are not assignable to other types by default – this is the most important protection TypeScript offers against the notorious “cannot read property of null” runtime errors.

// Primitives and type inference
const name = "Alice"; // inferred as string literal "Alice"
let age: number = 31;
let isActive: boolean = true;

// Union types
let id: string | number = "user-123";
id = 42; // valid

// Literal types
type Direction = "north" | "south" | "east" | "west";
let heading: Direction = "north";
// heading = "up"; // Error: Type '"up"' is not assignable to type 'Direction'

// Null safety with strict mode
function greet(name: string | null): string {
 if (name === null) {
 return "Hello, stranger";
 }
 return `Hello, ${name}`; // TypeScript knows name is string here
}

// Type narrowing with typeof
function formatValue(value: string | number): string {
 if (typeof value === "number") {
 return value.toFixed(2); // number methods available
 }
 return value.toUpperCase(); // string methods available
}

// The 'unknown' type — safer than 'any'
function processInput(input: unknown): string {
 if (typeof input === "string") {
 return input.trim();
 }
 if (typeof input === "number") {
 return String(input);
 }
 throw new Error("Unsupported input type");
}

// Const assertions for readonly literal types
const config = {
 apiUrl: "https://api.example.com",
 timeout: 5000,
} as const;
// config.timeout = 6000; // Error: cannot assign to readonly property

One of the most powerful features in the TypeScript type system is discriminated unions – a pattern where a shared literal property (the “discriminant”) tells TypeScript which branch of a union you are in. This pattern eliminates entire categories of runtime bugs and is central to well-architected TypeScript codebases. The compiler exhaustively checks every branch and will warn you if you add a new variant to the union without handling it everywhere:

type Success<T> = { status: "success"; data: T };
type Failure = { status: "failure"; error: string };
type Result<T> = Success<T> | Failure;

function handleResult(result: Result<string[]>): void {
 switch (result.status) {
 case "success":
 console.log(result.data.join(", ")); // data is string[]
 break;
 case "failure":
 console.error(result.error); // error is string
 break;
 default:
 // Exhaustiveness check — result is 'never' here
 const _exhaustive: never = result;
 }
}

TypeScript’s structural type system means that two types are compatible if they have the same shape, regardless of their names. This is different from nominal type systems (like Java or C#) where two classes with identical fields are distinct types. Structural typing enables powerful patterns like duck typing and automatic interface satisfaction, but it also means you need to be deliberate about distinguishing types that happen to share the same structure – which is where branded types (covered in the Advanced section) come in.

Avoid any entirely in new TypeScript 6.0 projects. The any type disables all type checking for a value and propagates silently through function calls, defeating the entire purpose of using TypeScript. Use unknown when the type genuinely cannot be determined at compile time, and narrow it with runtime checks as shown above. If you are migrating a JavaScript codebase, use the ESLint rule @typescript-eslint/no-explicit-any to flag every any usage so you can eliminate them systematically.

Step 3 – Working with Interfaces and Type Aliases

Interfaces and type aliases are the two primary tools for naming and reusing object shapes in TypeScript. Understanding when to use each is one of the core skills separating intermediate TypeScript developers from beginners. This typescript for beginners section covers both in depth, including the key differences that affect real-world code.

The practical rule in 2026: use interfaces for object shapes that represent entities in your domain (users, products, API responses) because interfaces support declaration merging – essential when extending third-party library types. Use type aliases for unions, intersections, mapped types, and any shape that is not a plain object.

// Interface for domain entities
interface User {
 readonly id: string;
 email: string;
 name: string;
 role: "admin" | "editor" | "viewer";
 createdAt: Date;
 updatedAt?: Date; // optional property
}

// Extending interfaces
interface AdminUser extends User {
 role: "admin";
 permissions: string[];
}

// Declaration merging — useful for extending library types
interface Window {
 analyticsReady: boolean;
}

// Type alias for complex types
type UserWithoutId = Omit<User, "id">;
type CreateUserInput = Pick<User, "email" | "name" | "role">;
type UserRole = User["role"]; // "admin" | "editor" | "viewer"

// Intersection types
type AuditedEntity = {
 createdBy: string;
 updatedBy: string | null;
};

type AuditedUser = User & AuditedEntity;

// Index signatures for dynamic keys
interface Settings {
 [key: string]: string | number | boolean;
 theme: "light" | "dark"; // specific keys still type-checked
}

// Readonly utility type for immutable objects
type ImmutableUser = Readonly<User>;

// Record for key-value maps
type UserRole2 = "admin" | "editor" | "viewer";
type RolePermissions = Record<UserRole2, string[]>;

const permissions: RolePermissions = {
 admin: ["read", "write", "delete"],
 editor: ["read", "write"],
 viewer: ["read"],
};

A common beginner mistake is creating excessively nested interfaces that mirror a database schema one-to-one. Instead, use TypeScript’s utility types – Partial, Required, Pick, Omit, Readonly, and Record – to derive related types from a single source of truth. When your User interface changes, all derived types update automatically, preventing the “forgot to update the update type” bug that plagues large codebases.

Template literal types allow you to create string types dynamically. This is particularly powerful for typed API route definitions and event names:

type HttpMethod = "GET" | "POST" | "PUT" | "DELETE" | "PATCH";
type ApiVersion = "v1" | "v2";
type ApiRoute = `/${ApiVersion}/${string}`;

// Valid: "/v1/users", "/v2/products/123"
// Invalid: "/v3/users" — type error at compile time

type EventName = `on${Capitalize<string>}`;
// Valid: "onClick", "onChange", "onSubmit"

// Mapped type for transforming all method names to async
type AsyncMethods<T> = {
 [K in keyof T]: T[K] extends (...args: infer A) => infer R
 ? (...args: A) => Promise<R>
 : T[K];
};

The distinction between interface and type matters most when you are building a library or framework where consumers will extend your types. Interfaces are open for extension via declaration merging; type aliases are closed. For application code where you control all the types, the practical difference is minimal – choose whichever reads more clearly in context.

Step 4 – Functions, Generics, and Type Guards

Generics are TypeScript’s mechanism for writing reusable, type-safe code that works across multiple types without sacrificing type information. They are the feature that makes utility libraries like Zod, tRPC, and Prisma possible, and they are the feature most beginners skip – leading to overuse of any and loss of type safety. This section of our typescript tutorial demystifies generics with practical examples you can apply immediately.

// Generic functions
function first<T>(array: T[]): T | undefined {
 return array[0];
}

const firstNumber = first([1, 2, 3]); // number | undefined
const firstString = first(["a", "b"]); // string | undefined

// Generic with constraints
function getProperty<T, K extends keyof T>(obj: T, key: K): T[K] {
 return obj[key];
}

const user = { id: "1", name: "Alice", age: 30 };
const userName = getProperty(user, "name"); // string
// getProperty(user, "email"); // Error: not a key of user

// Generic interfaces
interface Repository<T> {
 findById(id: string): Promise<T | null>;
 findAll(filter?: Partial<T>): Promise<T[]>;
 create(data: Omit<T, "id" | "createdAt">): Promise<T>;
 update(id: string, data: Partial<T>): Promise<T | null>;
 delete(id: string): Promise<boolean>;
}

// Type guard functions
interface User {
 id: string;
 email: string;
 name: string;
}

function isUser(value: unknown): value is User {
 return (
 typeof value === "object" &&
 value !== null &&
 "id" in value &&
 "email" in value &&
 typeof (value as Record<string, unknown>).email === "string"
 );
}

// Assertion functions (TS 3.7+, standard practice in 2026)
function assertNonNull<T>(
 value: T,
 message: string
): asserts value is NonNullable<T> {
 if (value === null || value === undefined) {
 throw new Error(message);
 }
}

// Function overloads
function format(value: string): string;
function format(value: number, decimals: number): string;
function format(value: string | number, decimals = 0): string {
 if (typeof value === "string") return value.trim();
 return value.toFixed(decimals);
}

// Const type parameters (TS 5.0+) for precise literal inference
function makeArray<const T>(value: T): T[] {
 return [value];
}
const arr = makeArray("hello"); // string[], not ("hello")[]
const arr2 = makeArray(42 as const); // 42[] preserving the literal

Type guards are runtime functions that return a boolean telling TypeScript what type a value has inside the if block that follows. The value is User return type syntax is a type predicate – it narrows the type of value inside any block where the guard returns true. This pattern is essential whenever you receive data from an external source (API responses, form inputs, file contents) and need to validate it before using it with full type safety.

For production-grade runtime validation, pair TypeScript’s compile-time checks with a runtime validation library. Zod is the most popular choice in 2026. Zod schemas double as both runtime validators and TypeScript type generators, eliminating the duplication of maintaining separate interface and validation logic. The pattern type User = z.infer<typeof UserSchema> means your schema and your type are always in sync by construction.

Step 5 – Classes, Decorators, and Object-Oriented Patterns

TypeScript’s class support goes well beyond what JavaScript classes offer. Parameter properties, access modifiers, abstract classes, and decorators give you a complete object-oriented toolkit. Decorators in particular have undergone a major stabilisation cycle – TypeScript 5.0 shipped the TC39 Stage 3 decorator specification, and by 2026 they are widely used in frameworks like Angular, NestJS, and TypeORM.

// Abstract base class with generics
abstract class BaseService<T extends { id: string }> {
 protected items: Map<string, T> = new Map();

 abstract validate(data: Partial<T>): boolean;

 findById(id: string): T | undefined {
 return this.items.get(id);
 }

 getAll(): T[] {
 return Array.from(this.items.values());
 }

 protected generateId(): string {
 return crypto.randomUUID();
 }
}

// Concrete implementation with parameter properties
interface Logger {
 info(message: string): void;
 error(message: string): void;
}

interface CreateUserInput {
 email: string;
 name: string;
 role: "admin" | "editor" | "viewer";
}

interface User extends CreateUserInput {
 id: string;
 createdAt: Date;
}

class UserService extends BaseService<User> {
 // Parameter property: shorthand for this.logger = logger
 constructor(private readonly logger: Logger) {
 super();
 }

 validate(data: Partial<User>): boolean {
 if (!data.email || !/^[^s@]+@[^s@]+.[^s@]+$/.test(data.email)) {
 return false;
 }
 return true;
 }

 async createUser(input: CreateUserInput): Promise<User> {
 if (!this.validate(input)) {
 throw new Error("Invalid user data");
 }
 const user: User = {
 ...input,
 id: this.generateId(),
 createdAt: new Date(),
 };
 this.items.set(user.id, user);
 this.logger.info(`Created user ${user.id}`);
 return user;
 }
}

// Stage 3 Decorators (TC39, TypeScript 5.0+)
function Log(
 target: (this: unknown, ...args: unknown[]) => unknown,
 context: ClassMethodDecoratorContext
) {
 const methodName = String(context.name);
 return function (this: unknown, ...args: unknown[]) {
 console.log(`[${methodName}] called with`, args);
 const result = target.apply(this, args);
 console.log(`[${methodName}] returned`, result);
 return result;
 };
}

class MathService {
 @Log
 add(a: number, b: number): number {
 return a + b;
 }
}

Access modifiers (private, protected, public, readonly) in TypeScript are compile-time only – they do not exist at runtime in the emitted JavaScript. For true runtime privacy, use the JavaScript private field syntax (#field) instead of TypeScript’s private keyword. TypeScript supports both and enforces the distinction. The # syntax is preferable when you need the encapsulation to hold at runtime – for serialization, reflection, or interoperability with plain JavaScript code that uses your class.

Abstract classes serve a different purpose from interfaces: they can contain implementation, not just shape. Use abstract classes when you have a family of related classes that share a significant amount of logic but differ in a small number of abstract operations. Use interfaces when you only need to define a contract and implementations may come from unrelated parts of the codebase.

Step 6 – Working with Modules and Modern ES Imports

Module handling is the area where TypeScript beginners most often encounter confusing errors – “Cannot find module”, “ESM only”, “require is not a function”. TypeScript 6.0 made a decisive move to ES modules as the default, aligning with the broader JavaScript ecosystem. This section explains exactly how TypeScript module resolution works in 2026 and how to avoid the most common pitfalls.

With "module": "ESNext" and "moduleResolution": "bundler" in your tsconfig.json, TypeScript resolves imports the same way Vite, esbuild, and webpack 5 do. You do not need to add .js extensions to your imports when using the bundler resolution mode – the bundler handles it. However, if you are publishing a library or running directly with Node.js (without a bundler), you need to include the .js extension in your TypeScript source even though the file is actually a .ts file. For more on bundler comparisons, see our Vite vs Webpack 2026 guide.

// For bundler projects (Vite, webpack): no extension needed
import { UserService } from "./services/user";
import type { User, CreateUserInput } from "./types/user";

// For Node.js ESM without a bundler: use .js extension
import { UserService } from "./services/user.js";

// Dynamic imports — fully typed
async function loadPlugin(name: string) {
 const plugin = await import(`./plugins/${name}.js`);
 return plugin.default;
}

// Import type — erased at compile time, zero runtime cost
import type { Request, Response, NextFunction } from "express";

// Namespace imports
import * as path from "node:path";
import * as fs from "node:fs/promises";

// Re-exports
export { UserService } from "./services/user.js";
export type { User } from "./types/user.js";

// Barrel files (use sparingly — can harm tree-shaking)
// src/index.ts
export * from "./services/user.js";
export * from "./services/product.js";

// Path aliases in tsconfig.json
// "paths": { "@/*": ["./src/*"] }
// Then in code:
import { config } from "@/config/env";

The import type syntax is important for two reasons. First, it guarantees the import is erased at compile time, producing no runtime code – this matters for avoiding circular dependency issues and for keeping bundle sizes small. Second, with verbatimModuleSyntax (a TypeScript 5.0+ option gaining wide adoption in 2026), TypeScript will error if you use a regular import for a type-only import, enforcing the distinction explicitly and ensuring your bundler can properly tree-shake your code.

Path mapping via paths in tsconfig.json lets you create clean import aliases instead of relative paths like ../../../services/user. Add paths configuration and the corresponding bundler alias configuration (Vite’s resolve.alias or webpack’s resolve.alias) together – TypeScript’s paths only affects type checking, not the actual module resolution at runtime or build time. Tools like tsc-alias can transform paths in the compiled output if you are not using a bundler.

Step 7 – Building a Complete REST API Project with TypeScript

This is the centrepiece of this typescript tutorial 2026: a complete, production-structured REST API built with Express and TypeScript 6.0. The API manages a collection of products and demonstrates typed request/response objects, middleware, error handling, dependency injection, and the repository pattern – the architectural building blocks you will encounter in every professional TypeScript project.

Install the required dependencies:

npm install express zod
npm install --save-dev @types/express tsx

Create the following file structure in your src/ directory:

src/
├── types/
│ └── product.ts
├── repositories/
│ └── product.repository.ts
├── services/
│ └── product.service.ts
├── controllers/
│ └── product.controller.ts
├── middleware/
│ └── error.middleware.ts
└── index.ts

Here is the complete, working implementation for each file:

// src/types/product.ts
import { z } from "zod";

export const ProductSchema = z.object({
 id: z.string().uuid(),
 name: z.string().min(1).max(200),
 price: z.number().positive(),
 category: z.enum(["electronics", "clothing", "food", "books"]),
 inStock: z.boolean(),
 createdAt: z.date(),
 updatedAt: z.date().optional(),
});

export const CreateProductSchema = ProductSchema.omit({
 id: true,
 createdAt: true,
 updatedAt: true,
});

export const UpdateProductSchema = CreateProductSchema.partial();

export type Product = z.infer<typeof ProductSchema>;
export type CreateProductInput = z.infer<typeof CreateProductSchema>;
export type UpdateProductInput = z.infer<typeof UpdateProductSchema>;

// -------------------------------------------------------
// src/repositories/product.repository.ts
// -------------------------------------------------------
export interface IProductRepository {
 findAll(): Promise<Product[]>;
 findById(id: string): Promise<Product | null>;
 create(data: CreateProductInput): Promise<Product>;
 update(id: string, data: Partial<Product>): Promise<Product | null>;
 delete(id: string): Promise<boolean>;
}

export class InMemoryProductRepository implements IProductRepository {
 private products: Map<string, Product> = new Map();

 async findAll(): Promise<Product[]> {
 return Array.from(this.products.values());
 }

 async findById(id: string): Promise<Product | null> {
 return this.products.get(id) ?? null;
 }

 async create(data: CreateProductInput): Promise<Product> {
 const product: Product = {
 ...data,
 id: crypto.randomUUID(),
 createdAt: new Date(),
 };
 this.products.set(product.id, product);
 return product;
 }

 async update(id: string, data: Partial<Product>): Promise<Product | null> {
 const existing = this.products.get(id);
 if (!existing) return null;
 const updated: Product = { ...existing, ...data, updatedAt: new Date() };
 this.products.set(id, updated);
 return updated;
 }

 async delete(id: string): Promise<boolean> {
 return this.products.delete(id);
 }
}

// -------------------------------------------------------
// src/services/product.service.ts
// -------------------------------------------------------
export class ProductService {
 constructor(private readonly repository: IProductRepository) {}

 async getAllProducts(): Promise<Product[]> {
 return this.repository.findAll();
 }

 async getProductById(id: string): Promise<Product> {
 const product = await this.repository.findById(id);
 if (!product) {
 throw Object.assign(new Error(`Product ${id} not found`), {
 statusCode: 404,
 });
 }
 return product;
 }

 async createProduct(input: CreateProductInput): Promise<Product> {
 return this.repository.create(input);
 }

 async updateProduct(id: string, input: UpdateProductInput): Promise<Product> {
 await this.getProductById(id); // throws 404 if not found
 const updated = await this.repository.update(id, input);
 return updated!;
 }

 async deleteProduct(id: string): Promise<void> {
 await this.getProductById(id);
 await this.repository.delete(id);
 }
}

// -------------------------------------------------------
// src/controllers/product.controller.ts
// -------------------------------------------------------
import type { Request, Response, NextFunction } from "express";

export class ProductController {
 constructor(private readonly service: ProductService) {}

 getAll = async (
 _req: Request,
 res: Response,
 next: NextFunction
 ): Promise<void> => {
 try {
 const products = await this.service.getAllProducts();
 res.json({ data: products, count: products.length });
 } catch (error) {
 next(error);
 }
 };

 getById = async (
 req: Request<{ id: string }>,
 res: Response,
 next: NextFunction
 ): Promise<void> => {
 try {
 const product = await this.service.getProductById(req.params.id);
 res.json({ data: product });
 } catch (error) {
 next(error);
 }
 };

 create = async (
 req: Request,
 res: Response,
 next: NextFunction
 ): Promise<void> => {
 try {
 const input = CreateProductSchema.parse(req.body);
 const product = await this.service.createProduct(input);
 res.status(201).json({ data: product });
 } catch (error) {
 next(error);
 }
 };

 update = async (
 req: Request<{ id: string }>,
 res: Response,
 next: NextFunction
 ): Promise<void> => {
 try {
 const input = UpdateProductSchema.parse(req.body);
 const product = await this.service.updateProduct(req.params.id, input);
 res.json({ data: product });
 } catch (error) {
 next(error);
 }
 };

 remove = async (
 req: Request<{ id: string }>,
 res: Response,
 next: NextFunction
 ): Promise<void> => {
 try {
 await this.service.deleteProduct(req.params.id);
 res.status(204).send();
 } catch (error) {
 next(error);
 }
 };
}

// -------------------------------------------------------
// src/middleware/error.middleware.ts
// -------------------------------------------------------
interface AppError extends Error {
 statusCode?: number;
}

export function errorMiddleware(
 err: AppError,
 _req: Request,
 res: Response,
 _next: NextFunction
): void {
 const statusCode = err.statusCode ?? 500;
 res.status(statusCode).json({
 error: err.message,
 ...(process.env.NODE_ENV === "development" && { stack: err.stack }),
 });
}

// -------------------------------------------------------
// src/index.ts
// -------------------------------------------------------
import express from "express";

const app = express();
app.use(express.json());

const repository = new InMemoryProductRepository();
const service = new ProductService(repository);
const controller = new ProductController(service);

const router = express.Router();
router.get("/", controller.getAll);
router.get("/:id", controller.getById);
router.post("/", controller.create);
router.put("/:id", controller.update);
router.delete("/:id", controller.remove);

app.use("/api/v1/products", router);
app.use(errorMiddleware);

const PORT = process.env.PORT ?? 3000;
app.listen(PORT, () => {
 console.log(`Server running on http://localhost:${PORT}`);
});

This project demonstrates four critical TypeScript patterns used in production codebases. The Repository pattern abstracts the data layer behind an interface, making it trivial to swap an in-memory store for a real database without changing service or controller code. Constructor dependency injection makes every class’s dependencies explicit and testable. Zod schema derivation ensures your types and validation are always in sync. Typed Express handlers with generic Request<Params, ResBody, ReqBody> types give you compile-time safety for route parameters and request bodies. For further context on how TypeScript changes frontend development, see our Angular vs React 2026 comparison.

Step 8 – Testing Your TypeScript Application

A TypeScript project without tests provides a false sense of security – the type system catches structural errors at compile time but says nothing about the correctness of your business logic at runtime. This section covers unit and integration testing with Vitest, the testing framework of choice for TypeScript projects in 2026, and shows you how to write tests that are themselves type-safe.

Install Vitest and the required testing utilities:

npm install --save-dev vitest @vitest/coverage-v8 supertest @types/supertest

Add test scripts to package.json and create a Vitest config file:

// vitest.config.ts
import { defineConfig } from "vitest/config";

export default defineConfig({
 test: {
 globals: true,
 environment: "node",
 coverage: {
 provider: "v8",
 reporter: ["text", "json", "html"],
 thresholds: {
 branches: 80,
 functions: 80,
 lines: 80,
 statements: 80,
 },
 },
 },
});

// src/services/__tests__/product.service.test.ts
import { describe, it, expect, vi, beforeEach } from "vitest";
import { ProductService } from "../product.service.js";
import type { IProductRepository } from "../../repositories/product.repository.js";
import type { Product } from "../../types/product.js";

const mockProduct: Product = {
 id: "550e8400-e29b-41d4-a716-446655440000",
 name: "Wireless Keyboard",
 price: 79.99,
 category: "electronics",
 inStock: true,
 createdAt: new Date("2026-01-15"),
};

function createMockRepository(): IProductRepository {
 return {
 findAll: vi.fn().mockResolvedValue([mockProduct]),
 findById: vi.fn().mockResolvedValue(mockProduct),
 create: vi.fn().mockResolvedValue(mockProduct),
 update: vi.fn().mockResolvedValue(mockProduct),
 delete: vi.fn().mockResolvedValue(true),
 };
}

describe("ProductService", () => {
 let service: ProductService;
 let repository: IProductRepository;

 beforeEach(() => {
 repository = createMockRepository();
 service = new ProductService(repository);
 });

 describe("getProductById", () => {
 it("returns the product when found", async () => {
 const result = await service.getProductById(mockProduct.id);
 expect(result).toEqual(mockProduct);
 expect(repository.findById).toHaveBeenCalledWith(mockProduct.id);
 });

 it("throws a 404 error when the product is not found", async () => {
 vi.mocked(repository.findById).mockResolvedValue(null);
 await expect(
 service.getProductById("unknown-id")
 ).rejects.toMatchObject({
 message: expect.stringContaining("not found"),
 statusCode: 404,
 });
 });
 });

 describe("createProduct", () => {
 it("delegates creation to the repository", async () => {
 const input = {
 name: "Wireless Keyboard",
 price: 79.99,
 category: "electronics" as const,
 inStock: true,
 };
 await service.createProduct(input);
 expect(repository.create).toHaveBeenCalledWith(input);
 });
 });
});

The key principle demonstrated above is testing through interfaces. The mock repository satisfies the IProductRepository interface – TypeScript will give a compile error if you forget to implement a method or implement it with the wrong signature. This means your test infrastructure is as type-safe as your production code. Refactoring a repository method signature automatically breaks the mock and reminds you to update the test, preventing the “tests pass but production is broken” scenario that haunts untyped codebases.

Run the test suite with coverage:

npm run test:coverage
# Output:
# PASS src/services/__tests__/product.service.test.ts
#
# Coverage report:
# Statements: 92.31%
# Branches: 88.46%
# Functions: 100%
# Lines: 92.31%

For integration tests that test the full HTTP stack, use supertest against your Express app without starting a server – import the app instance and pass it to supertest directly. This gives you full request/response cycle testing without port conflicts or asynchronous server startup issues.

Step 9 – Advanced TypeScript Patterns and Utility Types

Once you are comfortable with the fundamentals, these advanced patterns unlock the full expressive power of the TypeScript type system. Mapped types, conditional types, infer, and template literals together enable a style of type programming where the types themselves express complex constraints that would otherwise require runtime validation in untyped code. This section of the typescript guide is aimed at developers who want to move from writing correct TypeScript to writing elegant TypeScript.

// 1. Mapped types with modifiers
type Mutable<T> = {
 -readonly [K in keyof T]: T[K]; // removes readonly from every property
};

type RequiredDeep<T> = {
 [K in keyof T]-?: T[K] extends object ? RequiredDeep<T[K]> : T[K];
};

// 2. Conditional types with infer keyword
type UnpackPromise<T> = T extends Promise<infer U> ? U : T;
type Head<T extends unknown[]> = T extends [infer H, ...unknown[]] ? H : never;
type Tail<T extends unknown[]> = T extends [unknown, ...infer Rest] ? Rest : never;

// 3. Satisfies operator (TS 4.9+, essential pattern in 2026)
const palette = {
 red: [255, 0, 0],
 green: "#00ff00",
 blue: [0, 0, 255],
} satisfies Record<string, string | number[]>;
// palette.red is still number[], not string | number[]
// palette.green is still string, not string | number[]

// 4. Branded types for nominal typing
type UserId = string & { readonly __brand: "UserId" };
type ProductId = string & { readonly __brand: "ProductId" };

function createUserId(id: string): UserId {
 return id as UserId;
}

function getUserById(id: UserId): Promise<User | null> {
 // Cannot accidentally pass a ProductId here — compile error
 return Promise.resolve(null);
}

// 5. NoInfer utility type (TS 5.4+) to prevent unwanted type widening
function createStore<T>(
 initialState: T,
 validate: (state: NoInfer<T>) => boolean
): T {
 if (!validate(initialState)) throw new Error("Invalid initial state");
 return initialState;
}

// 6. Template literal types for type-safe event systems
type EventMap = {
 "user:created": { user: User };
 "user:deleted": { userId: string };
 "product:updated": { product: Product };
};

type EventName = keyof EventMap;

class TypedEventEmitter {
 emit<K extends EventName>(event: K, payload: EventMap[K]): void {
 // implementation
 }
 on<K extends EventName>(event: K, handler: (payload: EventMap[K]) => void): void {
 // implementation
 }
}

// 7. Builder pattern with accumulated type state
type HttpClientBuilder<T extends Record<string, unknown> = Record<string, never>> = {
 withBaseUrl(url: string): HttpClientBuilder<T & { baseUrl: string }>;
 withTimeout(ms: number): HttpClientBuilder<T & { timeout: number }>;
 build: "baseUrl" extends keyof T ? () => HttpClient : never;
};

interface HttpClient {
 get(path: string): Promise<unknown>;
}

The satisfies operator fills a gap that previously forced developers to choose between type inference and type checking. Without satisfies, annotating palette with a type would widen the individual property types, losing precise inference. With satisfies, you get both: the object is validated against the specified type at the definition site, but each property retains its narrowest inferred type everywhere the object is used. Branded types solve the nominal typing gap – two string types with different brands are incompatible, preventing accidental mixing of semantically different identifiers. Both patterns have become standard practice in TypeScript codebases in 2025-2026.

Step 10 – Production Build, Deployment, and CI/CD Integration

Writing excellent TypeScript code is only half the job. Getting it compiled, tested, and deployed reliably on every commit is the other half. This final step of the typescript project tutorial covers optimising your production build, configuring a Dockerfile for containerised deployment, and setting up a GitHub Actions pipeline that runs type checking, tests, and deployment automatically on every push.

Update your package.json scripts for a complete production workflow:

{
 "type": "module",
 "scripts": {
 "build": "npm run typecheck && tsc",
 "build:fast": "esbuild src/index.ts --bundle --platform=node --target=node22 --outfile=dist/index.js",
 "typecheck": "tsc --noEmit",
 "dev": "node --experimental-strip-types src/index.ts",
 "start": "node dist/index.js",
 "test": "vitest run",
 "test:coverage": "vitest run --coverage",
 "lint": "eslint src --ext .ts --max-warnings 0",
 "clean": "rm -rf dist"
 }
}

Create a two-stage Dockerfile that keeps your production image lean:

# Dockerfile
FROM node:22-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY tsconfig*.json ./
COPY src ./src
RUN npm run build

FROM node:22-alpine AS production
WORKDIR /app
ENV NODE_ENV=production
COPY package*.json ./
RUN npm ci --omit=dev && npm cache clean --force
COPY --from=builder /app/dist ./dist
USER node
EXPOSE 3000
HEALTHCHECK --interval=30s --timeout=3s 
 CMD node -e "fetch('http://localhost:3000/health').catch(()=>process.exit(1))"
CMD ["node", "dist/index.js"]

Create the GitHub Actions workflow at .github/workflows/ci.yml:

name: CI/CD Pipeline

on:
 push:
 branches: [main, develop]
 pull_request:
 branches: [main]

jobs:
 quality:
 name: Type Check, Lint, and Test
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 - uses: actions/setup-node@v4
 with:
 node-version: "22"
 cache: "npm"
 - run: npm ci
 - run: npm run typecheck
 - run: npm run lint
 - run: npm run test:coverage
 - uses: codecov/codecov-action@v4
 with:
 token: ${{ secrets.CODECOV_TOKEN }}

 build-and-push:
 name: Build and Push Docker Image
 needs: quality
 runs-on: ubuntu-latest
 if: github.ref == 'refs/heads/main'
 steps:
 - uses: actions/checkout@v4
 - uses: docker/setup-buildx-action@v3
 - uses: docker/login-action@v3
 with:
 registry: ghcr.io
 username: ${{ github.actor }}
 password: ${{ secrets.GITHUB_TOKEN }}
 - uses: docker/build-push-action@v5
 with:
 context: .
 push: true
 tags: ghcr.io/${{ github.repository }}:${{ github.sha }},ghcr.io/${{ github.repository }}:latest
 cache-from: type=gha
 cache-to: type=gha,mode=max

The two-stage Dockerfile produces an image 60-70% smaller than including the TypeScript compiler and source files. The builder stage installs all dev dependencies and compiles the TypeScript source. The production stage starts clean and copies only the compiled JavaScript plus production dependencies. The GitHub Actions workflow runs the full quality gate (type check, lint, tests with coverage) on every pull request, and only triggers the Docker build-and-push on merges to main. For a complete walkthrough of GitHub Actions pipelines, see our dedicated GitHub Actions CI/CD tutorial.

For Next.js-based frontend deployments using TypeScript, the workflow is similar but Vercel handles the build step. See our Next.js full-stack app tutorial for TypeScript configuration specific to the Next.js app router. Environment variables for production should always be validated at startup using Zod as shown in Step 7 – never access process.env values directly in production code without validation.

5 Common TypeScript Pitfalls and How to Avoid Them

Even experienced developers fall into these traps when working with TypeScript. This section documents the most costly mistakes seen in production codebases, with concrete guidance on how to avoid each one from day one of learning TypeScript.

1. Using any as an escape hatch. The temptation when a type error is hard to fix is to add : any and move on. This is the TypeScript equivalent of taking out a high-interest loan – you solve today’s problem by creating ten future ones. any silently disables type checking not just for the annotated value but for everything that value flows into downstream, defeating the entire purpose of using TypeScript. Use unknown instead, and write a type guard to narrow it. If you are working with genuinely untyped third-party data (config files, API responses, file contents), use Zod to parse and validate it at the boundary, deriving your TypeScript type from the Zod schema.
2. Disabling strict mode or adding // @ts-ignore comments. TypeScript 6.0 ships with strict: true as the default, and there is a reason: strict mode catches the categories of errors most likely to cause runtime crashes. Projects that disable strict mode or scatter @ts-ignore comments throughout the codebase accumulate type debt that becomes catastrophic during refactors. If a type error seems impossible to fix correctly, investigate it – it almost always reveals a genuine bug or a poorly designed type. Use @ts-expect-error rather than @ts-ignore when suppression is truly necessary, because it will fail loudly if the error it was suppressing disappears, preventing stale suppressions from silently hiding future issues.
3. Assuming TypeScript types survive to runtime. TypeScript’s type system is entirely a compile-time construct. At runtime, your application is plain JavaScript – no type checks, no interface enforcement, no enum values (unless you use const enums), and no generic constraints. Data arriving from outside your TypeScript boundary (HTTP requests, database queries, file system reads, localStorage, environment variables) has no type until you validate it explicitly at runtime. Always validate external data using Zod or a similar library even when TypeScript infers the shape looks correct, because that inference is only as reliable as the types you have declared for the external source.
4. Over-annotating when TypeScript can infer. A beginner reflex is to annotate every variable and function return type explicitly. This leads to verbose code like const name: string = "Alice" where the annotation adds no information. TypeScript infers types in most contexts, and inferring is preferable because it avoids annotation/implementation drift. Annotate function parameters (TypeScript cannot infer these), public API function return types (for documentation and to catch mistakes in the implementation), and cases where you want a wider type than TypeScript would infer (e.g., const value: string | null = null). Everything else can and should be inferred.
5. Mutating shared objects without defensive copies. TypeScript’s readonly modifier and the Readonly<T> utility type mark properties as non-writable at the type level, but the underlying JavaScript object is still mutable at runtime. If you return a Readonly<Product>Product and mutates it, TypeScript will not stop them at runtime. Use Object.freeze() when runtime immutability is essential, structure your code so mutations only happen at explicit state boundaries, or adopt Immer for immutable state management in complex scenarios.

TypeScript Troubleshooting Guide

The errors below cover the majority of issues developers encounter while learning and using TypeScript. Each row documents the exact error message, the most common cause, and the fastest path to resolution. This reference serves both the typescript for beginners audience encountering these for the first time and experienced developers who need a quick reference during a deep refactor or migration. The official TypeScript documentation contains the full error reference for edge cases not covered here.

Error Code & Message	Common Cause	Solution
TS2322: Type ‘X’ is not assignable to type ‘Y’	Structural mismatch: the value does not have all required properties, or a property has the wrong type	Hover the red squiggle in VS Code to see which property is mismatched. Use Partial<T> if the object is genuinely incomplete, or fix the source type to match the target.
TS2345: Argument of type ‘X | undefined’ is not assignable to parameter of type ‘X’	A value that may be undefined is passed to a function expecting a non-undefined value. Common with noUncheckedIndexedAccess enabled.	Add a null/undefined check before the call, use the nullish coalescing operator (??) to provide a default, or update the function signature to accept undefined.
TS2307: Cannot find module ‘./foo’ or its corresponding type declarations	File does not exist at the path, wrong extension, or @types package not installed for a JS library	Verify the file path and casing. For JS libraries, run: npm install –save-dev @types/library-name. For libraries without types, create a declarations.d.ts file.
TS1479: The current file is a CommonJS module whose imports will produce ‘require’ calls	Using ESM imports in a project configured for CommonJS, or missing “type”: “module” in package.json	Add “type”: “module” to package.json and set “module”: “ESNext” in tsconfig.json. Or convert to require() calls if CommonJS is intentional.
TS2339: Property ‘X’ does not exist on type ‘Y’	Accessing a property not in the type definition. Often a typo, or a property added dynamically at runtime.	Check spelling. If the property is genuinely dynamic, use an index signature. If extending a global type (e.g., Window), use declaration merging.
TS7006: Parameter ‘X’ implicitly has an ‘any’ type	Function parameter has no type annotation and TypeScript cannot infer its type from context	Add an explicit type annotation. Use unknown if the type is genuinely variable, then narrow with a type guard before use.
TS2454: Variable ‘X’ is used before being assigned	Variable declared with let but only assigned inside a conditional branch that may not execute	Initialise with a safe default value, use definite assignment assertion (let x!: string) when you know it will be assigned before use, or restructure the logic.
TS2551: Property ‘X’ does not exist on type ‘Y’. Did you mean ‘Z’?	Typo in a property or method name. TypeScript offers the closest match as a suggestion.	Accept TypeScript’s suggestion. Use the editor’s quick-fix (Ctrl+. / Cmd+.) to apply the correction automatically.
TS1005: Expected ‘;’ / TS1128: Declaration or statement expected	Syntax error – often from using TypeScript syntax in a .js file, or a missing closing brace or bracket	Rename the file to .ts, or locate the mismatched bracket using the error line number. The TypeScript language service underlines the specific token in VS Code.
Type instantiation is excessively deep and possibly infinite	A circular or deeply recursive generic type that exceeds TypeScript’s recursion depth limit during inference	Add explicit type parameters to break the inference chain. Simplify the recursive type structure. As a last resort, use @ts-expect-error with a comment documenting why.

Advanced Tips for TypeScript Development in 2026

Having covered the fundamentals and a complete project, these advanced practices separate senior TypeScript engineers from developers who merely know the syntax. These tips reflect patterns that emerged or became mainstream in 2025-2026 as the TypeScript ecosystem matured and the community converged on best practices.

Use TypeScript 7.0 (Project Corsa) Language Service Preview

TypeScript 7.0, codenamed Project Corsa, rewrites the TypeScript compiler in Go. While the full release is not yet stable as of April 2026, VS Code offers a preview via the TypeScript Nightly extension that uses the Go-based language service for dramatically faster IntelliSense, go-to-definition, and rename operations on large codebases. Projects with over 500,000 lines of TypeScript – common in monorepos – can expect 10x or better cold-start improvements for the language service. Enable it per workspace using "typescript.experimental.useTsgo": true in your VS Code workspace settings. The Go compiler is not yet used for actual tsc build pipelines, but the language service alone makes a measurable difference to daily development velocity. Check the official TypeScript docs for Project Corsa milestones. Also see how TypeScript compares to plain JavaScript in our TypeScript vs JavaScript 2026 guide.

Use Project References for Monorepo Type Safety

TypeScript’s project references feature (composite: true in tsconfig.json combined with a top-level references array) enables incremental builds and cross-package type checking in monorepos. Without project references, TypeScript has to compile every package from scratch on every change. With them, the compiler caches per-package output and only recompiles packages whose source has changed. In a monorepo with 20 packages, this can reduce type check times from several minutes to under 30 seconds. Set up project references alongside your package manager’s workspace feature (npm workspaces, pnpm workspaces) for a full-stack monorepo where the frontend package imports types from the backend package directly with full type safety and no duplication.

Use @typescript-eslint with Strict Rules

The TypeScript compiler catches type errors, but ESLint with @typescript-eslint catches a different category of problems: unused variables, floating promises, inconsistent return types, forbidden patterns, and more. The @typescript-eslint/strict and @typescript-eslint/stylistic rule sets are the recommended starting point in 2026. Key rules that prevent real bugs in production: @typescript-eslint/no-floating-promises (every Promise must be awaited or explicitly handled), @typescript-eslint/no-unsafe-assignment (prevents assigning any-typed values), and @typescript-eslint/consistent-type-imports (enforces import type for type-only imports). Run ESLint in CI alongside TypeScript type checking – they catch different categories of problems and together provide the strongest static analysis available for TypeScript.

Additional advanced practices worth adopting in 2026: use Zod for all external data validation (runtime safety matching compile-time types), adopt tRPC for end-to-end type-safe APIs in full-stack TypeScript projects (eliminates the entire category of frontend/backend type mismatch bugs), configure TypeScript path aliases with tsconfig-paths or Vite’s resolve.alias for clean imports in larger projects, and enable strict null checks combined with noUncheckedIndexedAccess from day one – retrofitting these into an existing codebase takes significantly longer than building with them from the start. For AI-assisted TypeScript development tooling, our AI coding tools guide covers which tools provide the best TypeScript understanding in 2026.

Frequently Asked Questions

These are the questions most commonly asked by developers following this typescript tutorial and learning TypeScript for the first time in 2026.

Do I need to know JavaScript before learning TypeScript?

Yes. TypeScript is a superset of JavaScript, meaning all valid JavaScript is valid TypeScript. You need a solid understanding of JavaScript fundamentals – variables, functions, objects, arrays, promises, and ES module syntax – before TypeScript’s type system will make sense. The type system annotates JavaScript concepts; if you do not understand the underlying JavaScript, the annotations will be confusing rather than clarifying. A practical JavaScript foundation (not mastery) is sufficient: aim to be comfortable with ES2020+ syntax, async/await, and destructuring before starting TypeScript. The learning curve for TypeScript itself is then much gentler.

What is the difference between TypeScript 6.0 and TypeScript 7.0?

TypeScript 6.0 (released early 2026) is the final version of the TypeScript compiler written in JavaScript/TypeScript. It ships with strict mode enabled by default, ES module resolution as the default, deprecation of older targets (ES3/ES5), and removal of import assertions in favour of import attributes. TypeScript 7.0 (Project Corsa) is a complete rewrite of the compiler and language service in Go. It does not change the TypeScript language itself – your TypeScript code will work identically – but it brings dramatically faster compilation and language service performance, particularly benefiting large monorepos. TypeScript 7.0’s Go-based language service is available as a VS Code preview today; the full compiler rewrite is in active development as of April 2026.

Should I use interfaces or type aliases?

For object shapes representing domain entities in your application, prefer interfaces because they support declaration merging (essential for extending library types) and produce clearer error messages in many cases. For unions, intersections, mapped types, conditional types, and type aliases derived from other types using utility types, use type. For library authors, interfaces are preferred for public API types that consumers may need to extend. The key practical difference is that interfaces are open (extendable via declaration merging) while type aliases are closed. For most application code where you control all types, the difference is minimal and consistency within a codebase matters more than the choice itself.

Can I run TypeScript directly without compiling it in 2026?

Yes, with Node.js v22.18.0 or later using the --experimental-strip-types flag. This strips type annotations at load time and runs the resulting JavaScript directly. It does not perform type checking – it is purely a syntax transform. For type checking, you still need to run tsc --noEmit separately. Tools like tsx and ts-node provide similar functionality with slightly different tradeoffs. For production, always compile with tsc or a bundler like esbuild/Vite to produce optimised, type-checked JavaScript output. The native Node.js TypeScript support is best understood as a development convenience, not a replacement for a proper build pipeline.

How do I migrate an existing JavaScript project to TypeScript?

The safest migration strategy is incremental. First, rename files from .js to .ts one at a time rather than all at once – TypeScript allows mixed JS/TS projects via allowJs: true. Second, start with strict: false and enable strict flags one at a time as you fix errors, rather than enabling all of them at once and being overwhelmed. Third, use // @ts-check comments at the top of JavaScript files you have not yet migrated – this enables TypeScript’s type checking on JS files without renaming them. Fourth, add JSDoc type annotations to untyped JavaScript functions before renaming to .ts – this gives TypeScript enough information to check the file before you have full TypeScript syntax. Plan for one to three months of incremental migration for a medium-sized JavaScript codebase.

Is TypeScript worth learning for frontend development with React or Angular?

Unambiguously yes. React’s official documentation now uses TypeScript in all examples as of 2025. Angular has required TypeScript since version 2 (2016) and its 2026 versions lean into advanced TypeScript features like signal-based reactivity with strict types. The component prop types, event handler signatures, and hook return types that TypeScript provides in a React or Angular codebase eliminate an entire class of integration bugs that are otherwise only caught at runtime. For component libraries published to npm, TypeScript provides the consumer-facing type definitions that make autocompletion and prop documentation work in their editors. There is essentially no scenario in 2026 where writing React or Angular in plain JavaScript is preferable to TypeScript for a team project. See our Angular vs React 2026 comparison for a detailed breakdown of TypeScript usage patterns in each framework.

How does TypeScript work with Vite for frontend projects?

Vite uses esbuild to transpile TypeScript files natively – it strips type annotations and outputs JavaScript without running type checking. This makes Vite’s TypeScript support extremely fast (esbuild is 10-100x faster than tsc for transpilation). The tradeoff is that Vite does not report type errors during development – it only transpiles. You must run tsc --noEmit (or vue-tsc for Vue projects) separately to see type errors, which is typically done as a separate CI step or via editor integration. The recommended Vite setup for TypeScript projects in 2026 uses "moduleResolution": "bundler" in tsconfig.json to match Vite’s module resolution behaviour. For a full comparison of build tooling, see our Vite vs Webpack 2026 guide.

What are the job prospects for TypeScript developers in 2026?

TypeScript is now listed as a required or preferred skill in the majority of JavaScript-related job postings. According to the Stack Overflow Developer Survey 2025, TypeScript is consistently ranked in the top five most-used languages and among the most-loved languages for the fifth consecutive year. Roles explicitly requiring TypeScript expertise – senior full-stack, frontend architecture, developer tooling – command a meaningful salary premium over equivalent JavaScript-only roles. The skill compounds well: TypeScript proficiency makes you a better JavaScript developer, a more effective Angular/React/Vue developer, a stronger Node.js backend developer, and a more confident contributor to open source libraries, all simultaneously. The investment in learning TypeScript from scratch pays dividends across every domain of web development.

Related Coverage

• TypeScript vs JavaScript: Complete Comparison for 2026 – side-by-side feature and performance analysis
• Next.js Full-Stack App Tutorial 2026 – build a complete app with the Next.js app router and TypeScript
• Angular vs React in 2026: Which Framework Should You Choose? – in-depth comparison with TypeScript integration for both
• Vite vs Webpack 2026: Build Tool Showdown – TypeScript compilation speeds, configuration, and ecosystem comparison
• GitHub Actions CI/CD Pipeline Tutorial 2026 – automate your TypeScript builds, tests, and deployments
• AI Coding Tools Guide (Pillar) – the best AI assistants for TypeScript development in 2026