Best Practices & Next Steps

Introduction

You've now covered TypeScript's core type system — from basic types through generics, enums, and narrowing. This final lesson focuses on the practical, real-world side: how to configure a project well, work with the wider ecosystem, and where to go from here.

Configuring Strict Mode

The single `"strict": true` flag in tsconfig.json actually bundles together a whole family of checks: `strictNullChecks` (null and undefined must be handled explicitly), `noImplicitAny` (every value must have a known type), `strictFunctionTypes`, and several others. Turning strict mode on catches dramatically more real bugs, and it is far easier to start a project strict than to retrofit it onto a large, already-loose codebase later.

Project Structure and tsconfig

A well-organized tsconfig.json typically separates source from compiled output using `rootDir` and `outDir`, limits compilation scope with `include`/`exclude`, and can define path aliases so imports like `@/components/Button` resolve cleanly instead of long relative paths like `../../../components/Button`.

{
  "compilerOptions": {
    "strict": true,
    "target": "ES2020",
    "rootDir": "src",
    "outDir": "dist",
    "baseUrl": ".",
    "paths": {
      "@/*": ["src/*"]
    }
  },
  "include": ["src"],
  "exclude": ["node_modules", "dist"]
}

Working with Third-Party Types

Many npm packages ship their own type declarations (.d.ts files) built in, so importing them just works with full autocomplete. For older or plain-JavaScript-only packages, the community-maintained DefinitelyTyped project publishes matching type packages under the `@types/` scope.

# For a library without built-in types
npm install --save-dev @types/lodash

Linting and Formatting

The TypeScript compiler checks types, but doesn't enforce style or catch every code-quality issue. ESLint with the `@typescript-eslint` plugin adds type-aware linting rules (like flagging unused variables or unsafe `any` usage), while Prettier handles automatic code formatting — the two are commonly used together, running alongside `tsc` in CI.

TypeScript with Frameworks

React components are typically written in `.tsx` files, typing props with an interface. Next.js has TypeScript support built in with zero configuration. Node.js backends add `@types/node` (and `@types/express` for Express) for full typings of the runtime and framework APIs. Angular is TypeScript-first by design, and modern runtimes like Deno and Bun understand TypeScript natively, with no separate compile step required during development.

interface ButtonProps {
  label: string;
  onClick: () => void;
}

function Button({ label, onClick }: ButtonProps) {
  return <button onClick={onClick}>{label}</button>;
}

Migrating JavaScript to TypeScript

You do not need to convert an entire codebase at once. The standard approach is incremental: enable `allowJs` and `checkJs` so TypeScript can type-check plain .js files using JSDoc comments, then rename files from .js to .ts one at a time, starting with the most-used, most-stable modules. Many teams start with a looser tsconfig on legacy code, then tighten `strict` settings gradually as more of the codebase is converted.

Common Mistakes

Best Practices

Frequently Asked Questions

Key Takeaways

Summary

Congratulations — you've completed the TypeScript course, from what TypeScript is and why Microsoft built it, through the full type system, object-oriented programming, generics, and now real-world project practices. The best next step is to build something real: add TypeScript to a small project, turn on strict mode, and let the compiler guide you as you go.