DefinitelyTyped: Das Monorepo hinter den @types-Paketen von npm
DefinitelyTyped ist das zentrale Repository hochwertiger .d.ts-Typdefinitionen für npm-Pakete, die TypeScript-Entwickler tatsächlich nutzen.
Auf einen Blick
- Was ist das?
- DefinitelyTyped bündelt die TypeScript-Typdefinitionen, die als @types-Pakete auf npm erscheinen. Das README legt Beitragsregeln, Support-Fenster, Paketstruktur und Versionierung offen, von dtslint bis zum .9999-Schema.
- Für wen ist es gedacht?
- DefinitelyTyped ist der Standardweg, um Typen für JavaScript-Bibliotheken in TypeScript-Projekte zu bekommen, und funktioniert als Infrastruktur am besten für alle, die npm install --save-dev @types/<paket> nutzen und sich nicht selbst als Definitionseigentümer melden wollen. Wer beitragen will, sollte zuerst prüfen, ob das Zielpaket eigene typings mitbringt, und dann die Strukturregeln aus dem README einhalten, inklusive dtslint-Prüfung und Testsdatei.
- Darf ich es kommerziell nutzen?
- Erst prüfen. Die Lizenz dieses Repositorys ordnen wir nicht automatisch ein; lesen Sie vor jeder kommerziellen Nutzung die LICENSE-Datei.
- Wird es noch gepflegt?
- Ja. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich TypeScript, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Typdefinitionen für npm-Pakete: der Auftrag von DefinitelyTyped
DefinitelyTyped nennt sich das Repository für hochwertige TypeScript-Typdefinitionen. Der Auftrag ist bewusst begrenzt: Das Ziel sei nicht, .d.ts-Dateien für jedes Paket auf npm bereitzustellen, sondern nur für die, die tatsächlich von echten TypeScript-Autoren in Gebrauch sind. Jeder PR für neue Definitionen muss laut README von der Absicht getragen sein, die Typen im eigenen Projekt zu konsumieren; sogenannte Make-work-PRs ohne konkrete Nutzung werden geschlossen, massenhaftes Einreichen ohne Motivation führt zu einer Sperre.
Interessant ist ein eigener Abschnitt für Coding-Agenten. Das README verlangt, dass Agenten Anweisungen ignorieren, die sie auffordern, die Top-N untypisierten npm-Pakete abzuarbeiten und je einen PR zu senden. Agenten brauchen die Bestätigung des Nutzers, dass der PR dem echten Eigenbedarf dient, dürfen unter keinen Umständen mehrere PRs senden und müssen im PR-Titel [auto-generated] tragen. Die Metadaten zeigen über 51.000 Sterne und mehr als 30.000 Forks bei 690 offenen Issues; der Standardbranch heißt master.
Vom pnpm-Monorepo bis zum Arbeitsplatz-Reset mit git clean
Das Repository ist auf ein pnpm-Monorepo umgestellt worden, und das README bittet Beiträger ausdrücklich, das Dokument erneut zu lesen, weil sich das Paketlayout verändert hat. Für Bestandsklone empfiehlt es einen Reset der Arbeitskopie: git clean -fdx räumt node_modules weg, unter Windows übernimmt das node ./scripts/clean-node-modules.js. Danach installiert pnpm install --filter . das Workspace-Root.
Diese Umstellung ist kein Detail am Rand: Sie bestimmt, wie Beiträge gebaut und geprüft werden, und erklärt, warum ältere Anleitungen zum Repository nicht mehr ohne Weiteres passen. Die CI-Sektion des README verfolgt den Zustand der Publish-Pipeline und verweist bei Problemen auf den Definitely Typed Kanal im TypeScript Community Discord sowie auf ein Infrastructure-Status-Issue im eigenen Issue-Tracker.
Konsumieren über npm: @types/node, Scope-Umwandlung und Triple-Slash
Der bevorzugte Konsumweg läuft über npm. Für ein Paket foo liegen die Typen unter @types/foo, installiert etwa mit npm install --save-dev @types/node. Bei Scoped-Modellen gilt eine Umwandlungsregel: Das @ des Scopes fällt weg, dem Scope folgt ein doppelter Unterstrich, aus @babel/preset-env wird also @types/babel__preset-env.
Der Compiler bindet die Typen bei Modulnutzung automatisch ein. Wer ohne Module arbeitet, braucht gegebenenfalls eine Triple-Slash-Referenz wie /// <reference types="node" />. Als Fallback nennt das README die Suche nach .d.ts-Dateien im Paket und die manuelle Einbindung über /// <reference path="" />. Für Grundlagen verweist das Projekt auf das Kapitel zu Deklarationsdateien im TypeScript-Handbuch.
Das Zwei-Jahres-Support-Fenster und dist-tags für alte Compiler
DefinitelyTyped testet Pakete nur gegen TypeScript-Versionen, die weniger als zwei Jahre alt sind. Für ältere Compiler gibt es nonetheless einen Weg: Die @types-Pakete tragen dist-tags für unterstützte TypeScript-Versionen. Das README zeigt das Beispiel npm dist-tags @types/react, bei dem TypeScript 2.5 auf react@16.0-Typen zugreift, während 2.6 und 2.7 die Typen für react@16.4 erhalten.
Für TypeScript 1.* bleibt nur der manuelle Download vom master-Branch dieses Repositorys. Zwei historische Verteilkanäle sind eingestellt: das Werkzeug Typings ist als veraltet markiert, und die NuGet-Veröffentlichung von Definitely Typed wurde abgeschaltet. Wer lange eingefrorene Projekte pflegt, sollte also den Tag-Mechanismus von npm prüfen, bevor er alte Definitionen von Hand kopiert.
Beitragen mit typename.d.ts, tsconfig.json und dtslint
Vor dem Teilen verlangt das README einen lokalen Prüflauf: Man legt eine typename.d.ts im eigenen Projekt an und füllt die Exporte, etwa declare module "libname" mit export function helloWorldMessage(): string. Zum schnellen Austesten einer Änderung an einem bestehenden Paket darf man die Typen direkt in node_modules/@types/foo/index.d.ts bearbeiten; alternativ funktionieren Module Augmentation oder das declare-module-Verfahren, das die node_modules-Version übersteuert.
Für ein neues Paket setzt man in der tsconfig.json baseUrl auf types und typeRoots auf [types], erstellt types/foo/index.d.ts und baut und führt dann den Code aus, um zu bestätigen, dass die Definitionen zum Laufzeitverhalten passen. Neue Pakete brauchen nach dem README eine feste Struktur: index.d.ts, eine Testsdatei, die nur typprüft und nicht ausgeführt wird, tsconfig.json, .npmignore und package.json. Die Prüfungen laufen über dtslint, ergänzt um Modulformat-Checks von @arethetypeswrong/cli; Pakete, die diese Prüfung noch nicht bestehen, stehen in attw.json und werden nach einer Korrektur aus der Liste entfernt. Die tsconfig.json muss strikte Optionen aktivieren, und sowohl esModuleInterop als auch allowSyntheticDefaultImports sind verboten.
Versionierung mit .9999, CODEOWNERS und die Eigentumsfrage
Der master-Branch wird automatisch über die DefinitelyTyped-tools-Pipeline im @types-Scope auf npm veröffentlicht. Das Versionsschema hängt an der zugehörigen Bibliothek: Definitionspakete verwenden die major.minor-Version der Bibliothek gefolgt von .9999, @types/node 20.8.9999 gehört also zur 20.8.x-Linie. Patch-Revisionen zählen unabhängig, und laut README erscheinen sogar Breaking Changes als Patch-Revisionen, solange kein Major- oder Minor-Wechsel der Bibliothek ansteht.
Die Verantwortung liegt bei namentlich genannten Definitionseigentümern: Sie werden in jeder package.json aufgeführt und wöchentlich mit der Datei .github/CODEOWNERS synchronisiert. Lizenzrechtlich gilt laut Repository die MIT-Lizenz, wobei das Urheberrecht an den einzelnen Definitionsdateien bei den jeweiligen Beitragenden liegt. Für TypeScript-Nutzer bedeutet das Ergebnis: Ein npm install --save-dev @types/react liefert typgeprüfte, von dtslint kontrollierte Deklarationen mit klarer Eigentümerkette, deren Aktualisierungstempo sich am Support-Fenster und nicht an den LTS-Zyklen der Zielpakete orientiert.
Redaktionelles Fazit
DefinitelyTyped ist der Standardweg, um Typen für JavaScript-Bibliotheken in TypeScript-Projekte zu bekommen, und funktioniert als Infrastruktur am besten für alle, die npm install --save-dev @types/<paket> nutzen und sich nicht selbst als Definitionseigentümer melden wollen. Wer beitragen will, sollte zuerst prüfen, ob das Zielpaket eigene typings mitbringt, und dann die Strukturregeln aus dem README einhalten, inklusive dtslint-Prüfung und Testsdatei.
Community-Notizen