Das Typsystem von TypeScript erkennt eine Reihe wichtiger Fehler, bevor der Code ausgeführt wird: Typkonflikte, fehlende Eigenschaften und fehlerhafte Funktionssignaturen. Was es jedoch nicht erkennt, sind Sicherheitslücken, die vom Datenfluss innerhalb der Anwendung abhängen, Architekturfehler, die sich mit der Zeit durch die Verschmelzung von Teams anhäufen, nicht mehr benötigte Exporte, die lange im Code verbleiben, nachdem ihre Aufrufer entfernt wurden, und Fehler in der asynchronen Programmierung, die zwar korrekt kompilieren, aber unter bestimmten Laufzeitbedingungen zu Fehlern führen. Statische Analysetools schließen diese Lücken, und die Wahl der richtigen Kombination hängt davon ab, wonach genau gesucht wird.
Dieser Leitfaden behandelt die wichtigsten Tools für TypeScript-Teams im Jahr 2026: die Linting-Ebene (ESLint mit typescript-eslint, Biome, OxcLint), die Sicherheitsebene (Semgrep, Snyk Code, SonarQube), die Architekturebene (Dependency-Cruiser, Deptrac, Nx), die Ebene für toten Code (Knip) und die Ebene für die detaillierte Codeanalyse (ts-morph, der TypeScript-Compiler selbst). Für jedes Tool wird erläutert, was es genau leistet, wie es konfiguriert wird und wann es für den jeweiligen Zweck ungeeignet ist.
Entwickelt für Codebasen, die niemand versteht
SMART TS XL Erzeugt automatisch bahnbrechende Änderungen in Ihrer gesamten Codebasis.
Erfahren Sie mehrTypeScript-Tools zur statischen Analyse: Vergleichstabelle
Bevor wir uns mit den einzelnen Tools befassen, ordnet die folgende Tabelle jedes Tool seiner Hauptfunktion, seiner Eignung für CI und seinem idealen Anwendungsfall zu. Kein einzelnes Tool deckt alle Dimensionen ab; eine effektive TypeScript-Qualitätsanalyse erfordert die Kombination mehrerer Tools.
| Werkzeug | Primärfunktion | CI-geeignet | Kosten | Am besten geeignet für |
|---|---|---|---|---|
| ESLint + typescript-eslint | Linting, Stil, typbezogene Regeln | Ja | Frei | Teamweite Konventionen, asynchrone Typsicherheit |
| Biom | Linting + Formatierung | Ja | Frei | ESLint + Schönerer Ersatz, Geschwindigkeit |
| OxcLint | Linting (ESLint-kompatibel) | Ja | Frei | Monorepos, die schnelle Lint-Zeiten benötigen |
| TypeScript-Compiler (tsc) | Typprüfung | Ja | Frei | Typfehler, strikte Mode-Erzwingung |
| Semgrep | SAST, individuelle Muster | Ja | Kostenlos + kostenpflichtig | Sicherheitsüberprüfung, benutzerdefinierte Organisationsregeln |
| Snyk-Code | SAST, Abhängigkeitssicherheit | Ja | Kostenlos + kostenpflichtig | Sicherheitsorientierte Teams, IDE-Integration |
| SonarQube / SonarCloud | Qualitätskontrolle, Trendverfolgung | Ja | Kostenlos + kostenpflichtig | Dashboards in Unternehmensqualität |
| SonarLint | Qualitätsfeedback auf IDE-Ebene | Nur IDE | Frei | Hinweise zu Sicherheit und Qualität im Text |
| Abhängigkeitskreuzer | Durchsetzung von Abhängigkeitsgraphen | Ja | Frei | Architekturregelvalidierung |
| Deptrac | Durchsetzung der Schichtgrenzen | Ja | Frei | Saubere Architektur, DDD-Grenzen |
| Nx | Monorepo-Abhängigkeitsmanagement | Ja | Kostenlos + kostenpflichtig | Monorepo-Modulgrenzen |
| Schnitt | Toter Code und ungenutzte Exporte | Ja | Frei | Reduzierung ungenutzten Codes in großem Umfang |
| ts-morph | Programmatische TS-AST-Analyse | Ausgewähltes Personal | Frei | Benutzerdefinierte Analysen, Codemodifikationen, Werkzeuge |
Schicht 1: Fussel und Stil
ESLint mit typescript-eslint
ESLint bleibt die Grundlage des TypeScript-Lintings. typescript-eslint Durch das Paket erhält es Zugriff auf die Typinformationen von TypeScript und kann Regeln durchsetzen, die einen Typkontext erfordern. Besonders wertvoll sind dabei die asynchronen Regeln, die häufige Promise-Fehler abfangen.
bash
npm install --save-dev typescript-eslintJavascript
// eslint.config.js
import tseslint from "typescript-eslint";
export default tseslint.config(
...tseslint.configs.strictTypeChecked,
{
languageOptions: {
parserOptions: {
project: true,
tsconfigRootDir: import.meta.dirname,
},
},
rules: {
// Async safety rules -- highest value TypeScript-specific rules
"@typescript-eslint/no-floating-promises": "error",
"@typescript-eslint/await-thenable": "error",
"@typescript-eslint/no-misused-promises": "error",
"@typescript-eslint/require-await": "warn",
// Type safety
"@typescript-eslint/no-explicit-any": "warn",
"@typescript-eslint/no-unsafe-assignment": "error",
"@typescript-eslint/no-unsafe-return": "error",
},
}
);Die vier oben genannten asynchronen Regeln stellen den größten Mehrwert dar, den typescript-eslint gegenüber dem einfachen ESLint bietet. Sie fangen Folgendes ab: nicht behandelte Promises (schwebende Promises), await angewendet auf Nicht-Promise-Werte, Promises, die an Callbacks übergeben werden, die synchrone Funktionen erwarten, und asynchrone Funktionen, die niemals verwendet werden awaitDies sind Muster, die zwar problemlos kompiliert werden, aber unter bestimmten Bedingungen zu Laufzeitfehlern führen.
Was ESLint nicht leisten kann : Analyse des Datenflusses zwischen Dateien, Durchsetzung architektonischer Grenzen, Verfolgung von Sicherheitslücken oder Erkennung nicht mehr benötigter Exporte. Hierfür sind die darunterliegenden Schichten erforderlich.
Biome: Das moderne ESLint + schönere Alternative
Biome ersetzt sowohl ESLint als auch Prettier durch eine einzige, auf Rust basierende Binärdatei, die 25- bis 35-mal schneller läuft. Es unterstützt JavaScript, TypeScript, JSX und JSON. Für neue Projekte oder Teams, die von der Plugin-Komplexität und der langsamen Performance von ESLint in großen Codebasen frustriert sind, ist Biome die leistungsstärkste moderne Alternative.
bash
npm install --save-dev --save-exact @biomejs/biome
npx @biomejs/biome initbash
# Check and format in one pass
npx @biomejs/biome check --write src/
# CI mode -- no modifications, exit non-zero on any finding
npx @biomejs/biome ci src/Das Plugin-Ökosystem von Biome ist kleiner als das von ESLint, was für Teams mit umfangreichen benutzerdefinierten Regeln oder frameworkspezifischen Plugins relevant ist. Für Teams, die lediglich die ESLint-Kernregeln und die Prettier-Formatierung nutzen, bietet Biome eine gleichwertige Testabdeckung in einem Bruchteil der Ausführungszeit.
OxcLint: Geschwindigkeit steht bei ESLint an erster Stelle
OxcLint (Teil des Oxc-Projekts) führt ESLint-kompatible Regeln 50- bis 100-mal schneller aus. Es ersetzt nicht das gesamte ESLint-Ökosystem, sondern ist die schnellste Option für CI-Pipelines, bei denen die Linting-Zeit einen Flaschenhals darstellt.
bash
npm install --save-dev oxlint
npx oxlint src/OxcLint ist die richtige Wahl für große Monorepos, bei denen Standard-ESLint Minuten benötigt und die Latenz der Feedbackschleife die Qualität von Pull Requests beeinträchtigt. Es funktioniert am besten parallel zu ESLint, anstatt es zu ersetzen. Verwenden Sie OxcLint für den schnellen Feedbackpfad und ESLint für die vollständige Regelabdeckung vor dem Merge-Vorgang.
Ebene 2: Typüberprüfung, der TypeScript-Compiler
Der TypeScript-Compiler (tsc) ist nicht nur ein Build-Tool, sondern die primäre statische Analyse-Engine für Typkorrektheit. Die Aktivierung des strikten Modus aktiviert die Einstellungen, die die meisten realen Fehler aufdecken:
JSON
{
"compilerOptions": {
"strict": true,
"noUnusedLocals": true,
"noUnusedParameters": true,
"noImplicitReturns": true,
"noFallthroughCasesInSwitch": true,
"exactOptionalPropertyTypes": true,
"useUnknownInCatchVariables": true
}
}bash
# Type-check only, no emit -- ideal for CI
npx tsc --noEmitnoUnusedLocals und noUnusedParameters Auf Compilerebene werden ungenutzte Variablen und Funktionsparameter abgefangen. useUnknownInCatchVariables (TypeScript 4.4+) Typen, die Ausnahmen abfangen, als unknown statt any, wodurch eine explizite Typeinschränkung vor der Verwendung erzwungen wird.
TypeScript-Kontrollflussanalyse ist eine integrierte Funktion des Compilers zur Typeneinschränkung innerhalb bedingter Verzweigungen. Es handelt sich nicht um ein separates Werkzeug, das Folgendes ermöglicht: strict Der Modus gewährleistet die uneingeschränkte Anwendung. Die Kontrollflussanalyse des Compilers versteht Typüberprüfungen, typeof Schecks, instanceofund diskriminierende Gewerkschaftsmuster.
Die Einschränkung von tsc : Der TypeScript-Compiler findet keine Sicherheitslücken, Architekturverletzungen oder tote Exporte. Er findet Typfehler, und zwar eindeutig.
Schicht 3: Sicherheit, SAST für TypeScript
Semgrep: Musterbasierte Sicherheitsprüfung
Semgrep findet Sicherheitslücken durch Code-Mustervergleich. Für TypeScript kann es SQL-Injection, XSS, fest codierte Anmeldeinformationen und unsicheren Code erkennen. eval Nutzung, Prototypenverschmutzung und unsichere Express.js-Konfigurationen, Muster, die zwar korrekt kompilieren, aber ausnutzbare Sicherheitslücken einführen.
YAML
# Custom rule: flag user input in SQL queries (TypeScript)
rules:
- id: ts-sql-injection-risk
patterns:
- pattern: |
const query = `SELECT ... ${$USER_INPUT} ...`;
message: "User input directly interpolated into SQL -- use parameterized queries"
languages: [typescript]
severity: ERRORbash
# Run with the community TypeScript security rules
semgrep scan --config=p/typescript --config=p/owasp-top-ten src/Semgrep ergänzt ESLint, es steht nicht im Wettbewerb. ESLint erzwingt Konventionen; Semgrep findet Sicherheitslücken. Die meisten TypeScript-Teams, denen Sicherheit wichtig ist, sollten beide Programme verwenden.
Snyk Code: ML-basierter SAST mit IDE-Integration
Snyk Code führt SAST mit einer maschinellen Lernalgorithmus-basierten Analyse-Engine durch, die Datenflüsse zwischen Dateien verfolgt. Es integriert sich in VS Code und JetBrains IDEs und zeigt die Ergebnisse direkt im Code an, anstatt auf einen CI-Lauf warten zu müssen.
bash
npm install --save-dev snyk
npx snyk auth
npx snyk code testDer Fokus von Snyk Code auf die Entwicklererfahrung, das integrierte IDE-Feedback, die Korrekturvorschläge zu jedem gefundenen Fehler und die Beispiele für die Behebung machen es zur besseren Wahl, wenn Sicherheitsschulung genauso wichtig ist wie die Sicherheitserkennung.
SonarQube und SonarLint: Qualitätsgates und Trendverfolgung
SonarQube bietet kontinuierliche Codequalitätsanalyse mit Dashboard, Trendverfolgung und Pull-Request-Dekoration. Für TypeScript erkennt es Fehler, Code-Smells, Sicherheitslücken und Duplikate. SonarLint ist die IDE-Erweiterung, die SonarQube-Regeln lokal bereitstellt.
Für TypeScript-Teams ist SonarCloud (die Cloud-basierte Version) der einfachere Weg: kostenlos für öffentliche Repositories, mit CI-Integration über GitHub Actions oder GitLab CI innerhalb von Minuten.
YAML
# .github/workflows/sonar.yml
- name: SonarCloud Scan
uses: SonarSource/sonarcloud-github-action@master
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}Der Hauptvorteil von SonarQube gegenüber reinem Linting liegt in seinem Trendmodell: Es zeigt, wie sich die Codequalität im Laufe der Zeit entwickelt, welche Komponenten sich verschlechtern und wie hoch der Qualitäts-Gate-Score für jeden Pull Request ist. Diese Management-relevanten Metriken sind das, was SonarQube leistet und ESLint und Semgrep nicht können.
Ebene 4: Architekturanalyse
Dependency-Cruiser: Modulgrenzenregeln durchsetzen
Dependency-Cruiser prüft, ob Ihr Importgraph den definierten Architekturregeln entspricht. Es generiert visuelle Abhängigkeitsgraphen und führt zu einem CI-Fehler, wenn Code gegen Modulgrenzen verstößt.
Javascript
// .dependency-cruiser.cjs
module.exports = {
forbidden: [
{
name: "no-circular",
severity: "error",
comment: "Circular dependencies make code hard to test and maintain",
from: {},
to: { circular: true },
},
{
name: "no-ui-in-domain",
severity: "error",
comment: "Domain modules must not import from UI layer",
from: { path: "^src/domain" },
to: { path: "^src/ui" },
},
{
name: "no-external-in-shared",
severity: "warn",
comment: "Shared utilities should minimize external dependencies",
from: { path: "^src/shared" },
to: { pathNot: "^(src|node_modules/(lodash|date-fns))" },
},
],
};bash
npx depcruise --validate .dependency-cruiser.cjs src/Dependency-Cruiser beantwortet direkt die Anfragen nach dem „react dependency analysis cli tool“ in den Search Console-Daten und ist das Standardwerkzeug zum Generieren und Validieren von Abhängigkeitsgraphen in TypeScript/React-Projekten.
Deptrac: Schichtbasierte Grenzüberwachung
Deptrac erzwingt Architekturschichten und stellt so sicher, dass Persistenzcode nicht aus der Präsentation importiert werden kann, dass Domänenobjekte nicht von der Infrastruktur abhängen und dass Modulgrenzen im gesamten Code eingehalten werden.
YAML
# deptrac.yaml
parameters:
layers:
- name: Domain
collectors:
- type: directory
value: src/domain
- name: Application
collectors:
- type: directory
value: src/application
- name: Infrastructure
collectors:
- type: directory
value: src/infrastructure
ruleset:
Domain:
- ~Infrastructure # Domain must not depend on Infrastructure
Application:
- Domain
Infrastructure:
- Application
- DomainDeptrac ist besonders wertvoll in Projekten, die den Mustern Clean Architecture, DDD oder Hexagonal Architecture folgen, wo die Isolation der Schichten eine Designvorgabe und nicht nur eine Frage der Präferenz ist.
Nx: Abhängigkeitsmanagement auf Monorepo-Ebene
Für TypeScript-Monorepos bietet Nx die Durchsetzung von Modulgrenzen, die Erkennung betroffener Builds und die Visualisierung des Abhängigkeitsgraphen über alle Projekte im Repository hinweg.
JSON
// .eslintrc.json -- Nx module boundary rules
{
"rules": {
"@nx/enforce-module-boundaries": [
"error",
{
"allow": [],
"depConstraints": [
{ "sourceTag": "scope:shared", "onlyDependOnLibsWithTags": ["scope:shared"] },
{ "sourceTag": "scope:feature", "onlyDependOnLibsWithTags": ["scope:shared", "scope:feature"] },
{ "sourceTag": "scope:app", "onlyDependOnLibsWithTags": ["scope:shared", "scope:feature"] }
]
}
]
}
}Nx's affected Die Befehle führen nur die Tests und Linting-Prüfungen aus, die für geänderte Module relevant sind, wodurch die CI-Zeit in großen Monorepos deutlich reduziert wird.
Schicht 5: Erkennung von totem Code
Knip: Unbenutzte Exporte, Dateien und Abhängigkeiten finden
Knip analysiert den gesamten Modulgraphen, um ungenutzte Exporte, ungenutzte Dateien und ungenutzte Ressourcen zu identifizieren. package.json Abhängigkeiten, die Art der Codeansammlung, die ESLint no-unused-vars kann nichts finden, da es nur innerhalb einer Datei sucht.
bash
npm install --save-dev knip
npx knipJSON
// knip.json
{
"entry": ["src/index.ts", "src/**/*.test.ts"],
"project": ["src/**/*.ts"],
"ignore": ["src/generated/**"],
"ignoreDependencies": ["vitest"]
}Knip wird in den SC-Daten direkt als „Dead Code Detection Unused Exports JavaScript TypeScript“ gesucht. Es ist das derzeit leistungsfähigste Tool zur Identifizierung von totem Code auf Modulebene in TypeScript-Projekten.
Schicht 6: Programmatische Analyse, ts-morph
ts-morph ist ein API-Wrapper für den TypeScript-Compiler, der das Schreiben von benutzerdefinierten Analysen, Codemodifikationen und Werkzeugen für den TypeScript-AST vereinfacht. Es wird direkt in den SC-Daten als „ts-morph“ und „ts morph“ gesucht.
Typoskript
import { Project } from "ts-morph";
const project = new Project({ tsConfigFilePath: "tsconfig.json" });
// Find all async functions that never await anything
const suspiciousAsyncFns: string[] = [];
for (const sourceFile of project.getSourceFiles()) {
for (const fn of sourceFile.getFunctions()) {
if (fn.isAsync()) {
const hasAwait = fn.getDescendantsOfKind(
SyntaxKind.AwaitExpression
).length > 0;
if (!hasAwait) {
suspiciousAsyncFns.push(
`${sourceFile.getFilePath()}:${fn.getName() ?? "anonymous"}`
);
}
}
}
}
console.log("Async functions with no await:", suspiciousAsyncFns);ts-morph ist kein sofort einsatzbereites Analysetool, sondern eine Bibliothek, mit der man ein solches Tool entwickeln kann. Es eignet sich für Teams, die über die Möglichkeiten bestehender Tools hinausgehende, individuelle Analysen benötigen: Migrationsskripte, benutzerdefinierte Architekturvalidatoren, automatisiertes Refactoring oder Codegenerierungspipelines.
Statische Analyse von TypeScript Async/Await
Die Daten der Search Console zeigen eine Häufung von Suchanfragen rund um „TypeScript Static Analysis Async Await Paper Tool“ und „TypeScript Static Analysis Async Await Vulnerability Paper Tool“. Diese Suchanfragen spiegeln wider, dass Anwender nach Tools suchen, die asynchrone Programmierfehler auf Typebene verstehen.
Die praktische Antwort für produktive TypeScript-Teams sind die vier asynchronen spezifischen Regeln von typescript-eslint (no-floating-promises, await-thenable, no-misused-promises, require-await) kombiniert mit strictNullChecks und useUnknownInCatchVariablesZusammen fangen diese die häufigsten asynchronen Typfehler ab, ohne dass akademische Forschungswerkzeuge benötigt werden.
Für Teams, die Sicherheitsforschung zu asynchronen Schwachstellenmustern betreiben, sind TAJS und Jelly akademische statische Analysatoren, die die asynchrone Ausführungssemantik von JavaScript modellieren. Es handelt sich jedoch um Forschungswerkzeuge und nicht um Werkzeuge für die Produktionsentwicklung.
Angular und React: Framework-spezifische statische Analyse
Für Angular-Teams, @angular-eslint Bietet Angular-spezifische Linting-Regeln für Komponentenmuster, Template-Analyse und Service-Injection. Es integriert sich in die oben genannte ESLint + typescript-eslint-Konfiguration.
Für React-Teams, hat das eslint-plugin-react, eslint-plugin-react-hooks und eslint-plugin-jsx-a11y Die Plugins decken React-spezifische Muster ab. Dependency-Cruiser übernimmt die Analyse von React-spezifischen Abhängigkeitsgraphen und ist das Tool hinter den Abfragen des „react dependency analysis cli tool“ in den SC-Daten.
IDE-Integration: Tools für VS Code und JetBrains
Die Suchanfragen „Beste Tools zur Codequalitätsverbesserung für die VS Code-Integration“ und „Beste Tools zur Codequalitätsverbesserung für die IDE-Integration“ spiegeln einen realen Bedarf wider: CI-Feedback kommt zu spät, um Verhaltensänderungen zu bewirken. Die in die IDE integrierte Analyse bietet den kürzesten Feedback-Kreislauf.
VS Code : ESLint-Erweiterung mit Clippy-Parität für Rust-Analyzer, SonarLint-Erweiterung für Inline-SonarQube-Regeln, Snyk-Erweiterung für Sicherheitsbefunde und der integrierte TypeScript-Sprachdienst für Feedback auf Typebene.
JetBrains (WebStorm/IntelliJ) : WebStorm bietet integrierte TypeScript-Unterstützung, die Typfehler direkt im Code anzeigt, sowie Integrationen mit ESLint, Prettier und SonarLint. Das integrierte Inspektionssystem deckt viele der gleichen Muster wie die ESLint-Regeln ab.
VS Code-Konfiguration für maximale TypeScript-Statikanalyseabdeckung :
JSON
// .vscode/settings.json
{
"typescript.tsdk": "node_modules/typescript/lib",
"typescript.enablePromptUseWorkspaceTsdk": true,
"editor.codeActionsOnSave": {
"source.fixAll.eslint": "explicit"
},
"eslint.validate": ["javascript", "typescript", "typescriptreact"],
"sonarlint.connectedMode.project": {
"connectionId": "my-sonarcloud",
"projectKey": "my-org_my-project"
}
}Wie SMART TS XL Erweitert die TypeScript-Analyse unternehmensweit
Die oben genannten Tools decken TypeScript innerhalb eines TypeScript-Projekts ab. In Organisationen, in denen TypeScript-Dienste mit COBOL-Batchprogrammen, Java-APIs, Python-Datenpipelines oder älteren Mainframe-Systemen interagieren, können Tools für einzelne Sprachen die sprachübergreifenden Abhängigkeiten nicht erkennen.
SMART TS XL statische Code-Analyse Es umfasst TypeScript sowie alle anderen Sprachen in Unternehmensumgebungen – COBOL, JCL, Java, Python, RPG, SQL – und erstellt ein einheitliches Abhängigkeitsmodell für alle diese Sprachen. Wenn ein TypeScript-Dienst eine API aufruft, die von einem COBOL-Programm unterstützt wird, SMART TS XL kann diese Beziehung nachverfolgen und einbeziehen in Wirkungsanalyse bevor an irgendeiner Komponente eine Änderung vorgenommen wird.
Die unternehmensweite Suchfunktion ermöglicht die Abfrage der gesamten mehrsprachigen Codebasis: Finden Sie innerhalb von Sekunden jeden TypeScript-Import eines bestimmten Moduls, jede Java-Methode, die von einem TypeScript-Dienst aufgerufen wird, jedes COBOL-Copybook, das Daten an eine von TypeScript genutzte API liefert, über Millionen von Codezeilen in beliebiger Sprachkombination.
Für Unternehmensteams, die TypeScript als eine Sprache in einem größeren Portfolio einsetzen, SMART TS XL bietet architektonische Sichtbarkeit und sprachübergreifende Kompatibilität Abhängigkeitszuordnung Das veranlasst TypeScript-spezifische Tools, ihren Teil des Systems zu untersuchen, während SMART TS XL sieht das Ganze.
Den richtigen Stack zusammenstellen
Kein einzelnes Tool deckt alle Qualitätsdimensionen für TypeScript ab. Der richtige Ansatz ist mehrschichtig, wobei jede Schicht auf eine bestimmte Problemklasse abzielt:
Minimaler funktionsfähiger Stack (neues Projekt, kleines Team):
- TypeScript-Strict-Modus
- ESLint mit typescript-eslint asynchronen Regeln
npm auditfür Abhängigkeitsschwachstellen
Produktionsanwendungs-Stack (mittelgroßes Team, sicherheitsbewusst):
- Alles oben, plus:
- Biome oder Prettier zum Formatieren
- Semgrep für Sicherheit SAST
- Knip für toten Code
- SonarCloud für hochwertige Trendanalyse
Enterprise-/Monorepo-Stack (großes Team, architektonische Einschränkungen):
- Alles oben, plus:
- Abhängigkeits-Cruiser zur Durchsetzung von Modulgrenzen
- Nx für die Optimierung von Builds, die von Monorepos betroffen sind
- Deptrac zur Validierung von Schichtgrenzen
- SonarQube (selbstgehostet) für hochwertige On-Premise-Gates
Polyglot-Unternehmensarchitektur (TypeScript neben Legacy-Systemen):
- Alles oben, plus:
- SMART TS XL für sprachübergreifende Wirkungsanalysen und Abhängigkeitsanalysen
