tsconfig.json
TypeScript-Tooling & Compiler-Optimierung

TypeScript (tsconfig.json) Konfigurations-Generator

Erstellen Sie moderne, robuste tsconfig.json-Konfigurationen für Next.js, Node.js, Vite oder Bibliotheken mit Strict Mode, Pfad-Aliasen und optimaler Modulauflösung.

100% Client-seitige Privatsphäre
Null Serverübertragung
Vorlagen:
Target & Modulauflösung
Integrierte Standard-Bibliotheksdefinitionen (lib):
Strikte Typprüfung
Ausgabe & Deklarationen
Bundler-Ausgabemodus: TypeScript fungiert rein als Typ-Checker. Ihr Bundler (Vite, Next.js, esbuild, Webpack) erzeugt die Laufzeit-Bundles.
Interop & Modulerkennung
Pfad-Mapping & Base URL
→
Include & Exclude
tsconfig.json TypeScript 5.x Bereit
Laufzeit-Ziel
ES2022 • preserve
Modulsystem
ESNext / bundler
Striktheits-Wert
100/100 • Strikte Typprüfung

100% Client-seitige Erstellung

Generieren und prüfen Sie TypeScript-Compileroptionen vollständig lokal im Browser ohne Server-Uploads.

TS 5.x & Moderne Bundler-Standards

Volle Unterstützung für verbatimModuleSyntax, isolatedDeclarations und moderne bundler-Auflösung.

Echtzeit-Diagnose & Audit

Erkennt widersprüchliche Compiler-Flags, veraltete Parameter und empfiehlt Best-Practice-Optimierungen.

Technische Referenz & Architektur-Leitfaden

TypeScript (tsconfig.json) Konfigurations-Generator Entwickler-Handbuch — Referenz-Leitfaden

Erstellen Sie moderne, robuste tsconfig.json-Konfigurationen für Next.js, Node.js, Vite oder Bibliotheken mit Strict Mode, Pfad-Aliasen und optimaler Modulauflösung.

Wichtige Parameter & Steuerelemente

targetEnum (ES5 | ES6/ES2015 - ES2023 | ESNext)

Legt die Ziel-ECMAScript-Version für generiertes JavaScript und Standard-Bibliothekstypen fest. Moderne Laufzeitumgebungen (Node.js 18+, Evergreen-Browser) sollten ES2022 oder ESNext verwenden.

Standard: ES2022
moduleResolutionEnum (Bundler | NodeNext | Node16 | Node10)

Bestimmt, wie TypeScript Import-Bezeichner physischen Dateien zuordnet. Nutzen Sie 'Bundler' für Vite, Turbopack oder Next.js und 'NodeNext' für native Node.js-ESM/CJS-Pakete.

Standard: Bundler
moduleEnum (ESNext | NodeNext | CommonJS | Preserve)

Definiert das Modulformat für die JavaScript-Ausgabe. 'ESNext' erzeugt moderne Import/Export-Syntax, ideal für moderne Bundler.

Standard: ESNext
strictBoolean (true | false)

Aktiviert die vollständige Palette strikter Typprüfungen, darunter strictNullChecks, noImplicitAny, strictFunctionTypes und strictPropertyInitialization.

Standard: true
jsxEnum (react-jsx | react-jsxdev | preserve | react)

Steuert, wie JSX-Konstrukte in .tsx-Dateien umgewandelt werden. 'react-jsx' importiert automatisch die moderne JSX-Runtime, ohne dass React im Scope sein muss.

Standard: react-jsx
isolatedModulesBoolean (true | false)

Gewährleistet, dass jede Datei von dateibasierten Transpilern wie Vite, esbuild, SWC oder Babel sicher und isoliert übersetzt werden kann.

Standard: true
skipLibCheckBoolean (true | false)

Überspringt die Typprüfung aller Deklarationsdateien (*.d.ts) in node_modules, was die Kompilierungszeit drastisch senkt, ohne die Anwendungstypsicherheit zu schwächen.

Standard: true

Profi-Tipps & Best Practices

Typprüfung vom Bundler trennen

Wenn Sie TypeScript zusammen mit Vite, Next.js, esbuild oder Turbopack einsetzen, aktivieren Sie 'noEmit: true' mit 'moduleResolution: Bundler'. Der Bundler übernimmt die hochoptimierte Mehrkern-Transpilierung, sodass tsc ausschließlich für die reine Typprüfung (tsc --noEmit) zuständig ist.

Pfad-Aliase ohne baseUrl anlegen

Definieren Sie Pfad-Aliase unter compilerOptions.paths (z. B. '@/*': ['./src/*']). Seit TypeScript 4.1 können Pfade direkt relativ zum Speicherort der tsconfig.json aufgelöst werden, auch ohne baseUrl, was Mehrdeutigkeiten in Monorepos vermeidet.

Inkrementelle Monorepo-Builds

Unterteilen Sie Monorepos (pnpm, Turborepo, Nx) in Teilprojekte mit 'composite: true' und 'declaration: true'. Die Verknüpfung über übergeordnete 'references' erlaubt es 'tsc --build', unveränderte Pakete via .tsbuildinfo-Cache blitzschnell inkrementell zu überspringen.

Definite Assignment bei ORMs

Bei der Verwendung von ORMs wie Prisma oder TypeORM mit aktiviertem strictPropertyInitialization können Fehler bei uninitialisierten Feldern auftreten. Deaktivieren Sie nicht den Strict-Modus global, sondern nutzen Sie die Definite-Assignment-Assertion ('title!: string') gezielt an Datenbank-Spalten.

Häufige Fallstricke & Fehlerbehebung

Fehler 'Cannot find module or its corresponding type declarations' beim Import moderner ESM-Pakete

Stellen Sie 'moduleResolution: Bundler' ein, wenn Sie Vite, Webpack 5 oder Next.js nutzen. Wenn Sie eine native Node.js-Anwendung entwickeln, wählen Sie 'moduleResolution: NodeNext' und stellen Sie sicher, dass relative Importe explizite Dateiendungen enthalten (z. B. import { util } from './util.js').

Pfad-Aliase (@/*) kompilieren mit tsc fehlerfrei, werfen zur Laufzeit aber 'Cannot find module'

Der TypeScript-Compiler schreibt Pfade in generierten JS-Dateien nicht um. Für Node.js-Laufzeiten verwenden Sie 'tsconfig-paths', 'tsx' oder native Node-Subpath-Imports über '#imports' in der package.json. Bei Frontend-Bundlern müssen Sie denselben Alias in der vite.config.ts bzw. webpack.config.js spiegeln.

Extrem langsame TypeScript-Kompilierung und zähe IDE-Rückmeldungen in großen Projekten

Aktivieren Sie 'skipLibCheck: true' in den compilerOptions. Dadurch wird die redundante Überprüfung von Deklarationsdateien in node_modules übersprungen, was die Build-Zeiten häufig um 50 % bis 70 % beschleunigt, ohne die Sicherheit Ihres eigenen Codes zu beeinträchtigen.

Häufig gestellte Fragen (FAQ)

Was ist der Unterschied zwischen moduleResolution 'Bundler' und 'NodeNext'?▼

'NodeNext' bildet das native ECMAScript-Modulauflösungsverhalten von Node.js präzise nach, verlangt zwingend Dateiendungen (.js) bei relativen Importen und honoriert die package.json-'exports'-Felder. 'Bundler' ist auf moderne Build-Tools (Vite, Webpack, esbuild) zugeschnitten, erlaubt das Weglassen von Erweiterungen, hybride ESM/CJS-Auflösung und den direkten Import von Nicht-JS-Ressourcen (CSS, SVG).

Warum wird strict: true für alle neuen TypeScript-Projekte dringend empfohlen?▼

'strict: true' aktiviert eine Reihe essenzieller Schutzmechanismen wie strictNullChecks und noImplicitAny. Dadurch werden typische Laufzeitfehler wie 'undefined is not a function' bereits während der Entwicklung eliminiert. Das nachträgliche Aktivieren in großen Projekten erfordert hohen Refactoring-Aufwand, weshalb ein sofortiger Start mit 'strict: true' Standard ist.

Wie interagieren target, module und lib in tsconfig.json?▼

'target' steuert die JavaScript-Sprachsyntax der Ausgabe (z. B. Klassen, Pfeilfunktionen oder async/await). 'module' bestimmt das Modulformat (z. B. CommonJS vs. ESM). 'lib' definiert, welche globalen Typdefinitionen (z. B. DOM, ES2022) der Compiler während der Prüfung bereitstellt, ohne den erzeugten JavaScript-Code selbst zu beeinflussen.

Was bewirkt isolatedModules: true und warum verlangen Tools wie Vite und SWC dies?▼

Tools wie esbuild, SWC und Babel transpilieren Dateien einzeln und parallel, ohne den vollständigen Projekt-Typbaum zu laden. TypeScript-Features wie 'const enum' oder reine Typ-Re-Exporte ohne 'export type' können bei isolierter Verarbeitung fehlerhaften Code erzeugen. 'isolatedModules: true' sorgt dafür, dass tsc solche inkompatiblen Muster vorab anmahnt.

Sollten .tsbuildinfo-Dateien und generierte Build-Verzeichnisse in Git versioniert werden?▼

Nein. Tragen Sie '*.tsbuildinfo' sowie Ausgabeverzeichnisse wie dist/, build/ und out/ in die .gitignore ein. Die .tsbuildinfo-Datei enthält maschinenspezifische Pfad-Hashes für inkrementelle Builds; Artefakte sollten stets reproduzierbar über Ihre CI/CD-Pipeline generiert werden.

Verwandte Werkzeuge & Dienstprogramme

Alle Werkzeuge →