System typów języka TypeScript wychwytuje istotną klasę błędów przed uruchomieniem kodu, niezgodności typów, brakujące właściwości i nieprawidłowe sygnatury funkcji. Nie wychwytuje jednak wszystkiego innego: luk w zabezpieczeniach zależnych od przepływu danych przez aplikację, naruszeń architektury, które kumulują się z czasem wraz z zacieraniem się granic między zespołami, nieaktywnych eksportów, które pozostają w bazie kodu długo po usunięciu ich wywołań, oraz błędów programowania asynchronicznego, które kompilują się poprawnie, ale nie działają w określonych warunkach środowiska uruchomieniowego. Narzędzia do analizy statycznej wypełniają te luki, a wybór odpowiedniej kombinacji zależy od tego, czego faktycznie szukasz.
W tym przewodniku omówiono narzędzia, które są istotne dla zespołów TypeScript w 2026 roku: warstwę lintingową (ESLint z TypeScript-eslint, Biome, OxcLint), warstwę bezpieczeństwa (Semgrep, Snyk Code, SonarQube), warstwę architektoniczną (Dependency-Cruiser, Deptrac, Nx), warstwę martwego kodu (Knip) oraz warstwę głębokiej analizy (ts-morph, sam kompilator TypeScript). W przypadku każdego z nich skupiono się na tym, co on faktycznie robi, jak go skonfigurować i kiedy nie jest odpowiednim narzędziem do danego zadania.
Zbudowany dla baz kodów, których nikt nie rozumie
SMART TS XL automatycznie wykrywa zmiany powodujące błędy w całej bazie kodu.
Ucz się więcejNarzędzia do analizy statycznej języka TypeScript: tabela porównawcza
Zanim przejdziemy do omówienia poszczególnych narzędzi, poniższa tabela przedstawia mapowanie każdego z nich pod kątem jego głównej funkcji, przydatności w kontekście CI oraz idealnego zastosowania. Żadne pojedyncze narzędzie nie obejmuje wszystkich aspektów, skuteczna analiza jakości języka TypeScript wymaga zastosowania kilku warstw.
| Narzędzie | Podstawowa funkcja | CI Odpowiednie | Koszty: | Najlepsze dla: |
|---|---|---|---|---|
| ESLint + typescript-eslint | Linting, styl, reguły uwzględniające typ | Tak | Darmowy | Konwencje obejmujące cały zespół, bezpieczeństwo typów asynchronicznych |
| Biom | Linting + formatowanie | Tak | Darmowy | ESLint + ładniejszy zamiennik, szybkość |
| OxcLint | Linting (zgodny z ESLint) | Tak | Darmowy | Monoreposy wymagające szybkiego czasu lintowania |
| Kompilator TypeScript (tsc) | Sprawdzanie typu | Tak | Darmowy | Błędy typu, egzekwowanie trybu ścisłego |
| Semgrep | SAST, niestandardowe wzorce | Tak | Bezpłatne + płatne | Skanowanie bezpieczeństwa, niestandardowe reguły organizacji |
| Kod Snyka | SAST, bezpieczeństwo zależności | Tak | Bezpłatne + płatne | Zespoły stawiające na bezpieczeństwo, integracja IDE |
| SonarQube / SonarCloud | Bramy jakości, śledzenie trendów | Tak | Bezpłatne + płatne | Panele jakości przedsiębiorstwa |
| SonarLint | Informacje zwrotne o jakości na poziomie IDE | Tylko IDE | Darmowy | Wskazówki dotyczące bezpieczeństwa i jakości w trybie online |
| Dependency-Cruiser | Wymuszanie grafu zależności | Tak | Darmowy | Walidacja reguł architektonicznych |
| Deptrac | Wymuszanie granic warstw | Tak | Darmowy | Czysta architektura, granice DDD |
| Nx | Zarządzanie zależnościami Monorepo | Tak | Bezpłatne + płatne | Granice modułu Monorepo |
| Wytnij | Martwy kod i nieużywane eksporty | Tak | Darmowy | Redukcja nieużywanego kodu na dużą skalę |
| ts-morph | Analiza programowa TS AST | Selektywny | Darmowy | Analiza niestandardowa, modyfikacje kodu, narzędzia |
Warstwa 1: Mechacenie i stylizacja
ESLint z typescript-eslint
ESLint pozostaje podstawą lintingu TypeScript. Dzięki typescript-eslint pakiet, uzyskuje dostęp do informacji o typie języka TypeScript i może egzekwować reguły wymagające kontekstu typu, z których najcenniejsze są reguły specyficzne dla asynchroniczności, które wychwytują typowe błędy Promise.
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",
},
}
);Cztery powyższe reguły asynchroniczne to reguły o największej wartości dodanej, jaką TypeScript-ESLINT zapewnia w porównaniu z ESLint. Wychwytują one: nieobsłużone obietnice (obietnice pływające), await stosowane do wartości niebędących obietnicami, obietnic przekazywanych do wywołań zwrotnych oczekujących funkcji synchronicznych oraz funkcji asynchronicznych, które nigdy nie są używane awaitSą to wzorce, które kompilują się bezproblemowo, ale w określonych warunkach powodują błędy w czasie wykonywania.
Czego ESLint nie potrafi : analizy przepływu danych między plikami, egzekwowania granic architektonicznych, śledzenia skażeń bezpieczeństwa ani wykrywania martwych eksportów. Do tego celu wymagane są pozostałe warstwy poniżej.
Biome: Nowoczesny ESLint + ładniejszy zamiennik
Biome zastępuje ESLint i Prettier jednym plikiem binarnym opartym na Rust, który działa 25-35 razy szybciej. Obsługuje JavaScript, TypeScript, JSX i JSON. Dla nowych projektów lub zespołów sfrustrowanych złożonością wtyczek ESLint i niską wydajnością w dużych bazach kodu, Biome jest najmocniejszą nowoczesną alternatywą.
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/Ekosystem wtyczek Biome jest mniejszy niż w ESLint, co ma znaczenie dla zespołów z rozbudowanymi regułami niestandardowymi lub wtyczkami specyficznymi dla frameworka. W przypadku zespołów korzystających jedynie z podstawowych reguł ESLint i formatowania Prettier, Biome zapewnia porównywalne pokrycie przy ułamku czasu wykonania.
OxcLint: Kompatybilność z ESLint Speed-First
OxcLint (część projektu Oxc) uruchamia reguły zgodne z ESLint z szybkością 50-100 razy większą. Nie zastępuje on pełnego ekosystemu ESLint, ale stanowi najszybszą opcję dla potoków CI, w których czas lintowania jest wąskim gardłem.
bash
npm install --save-dev oxlint
npx oxlint src/OxcLint to właściwy wybór dla dużych monorepozytoriów, gdzie standardowy ESLint zajmuje minuty, a opóźnienie pętli sprzężenia zwrotnego obniża jakość pull requestów. Najlepiej działa razem z ESLint, a nie zastępuje go. Uruchom OxcLint, aby uzyskać szybką ścieżkę sprzężenia zwrotnego, a ESLint, aby uzyskać pełne pokrycie reguł w bramce pre-merge.
Warstwa 2: Sprawdzanie typów, kompilator TypeScript
Kompilator TypeScript (tsc) to nie tylko narzędzie do kompilacji, ale także podstawowy silnik analizy statycznej do sprawdzania poprawności na poziomie typu. Włączenie trybu ścisłego aktywuje ustawienia, które wychwytują większość rzeczywistych błędów:
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 oraz noUnusedParameters na poziomie kompilatora wychwytuje nieużywane zmienne i parametry funkcji. useUnknownInCatchVariables (TypeScript 4.4+) typy wychwytywały wyjątki jako unknown zamiast any, wymuszając jawne zawężenie typu przed użyciem.
Analiza przepływu sterowania TypeScript to wbudowana funkcja kompilatora umożliwiająca zawężanie typów w gałęziach warunkowych. Nie jest to osobne narzędzie, umożliwiające strict Tryb zapewnia jego zastosowanie z pełną rygorystycznością. Analiza przepływu sterowania kompilatora uwzględnia ochronę typu, typeof sprawdza, instanceofi dyskryminowanych wzorców związków zawodowych.
Ograniczenie tsc : kompilator TypeScript nie wykrywa luk w zabezpieczeniach, naruszeń granic architektonicznych ani nieaktywnych eksportów. Znajduje błędy typu i robi to definitywnie.
Warstwa 3: Bezpieczeństwo, SAST dla TypeScript
Semgrep: skanowanie bezpieczeństwa oparte na wzorcach
Semgrep wykrywa luki w zabezpieczeniach poprzez dopasowywanie wzorców kodu. W przypadku TypeScript może wykrywać ataki typu SQL injection, XSS, zakodowane na stałe dane uwierzytelniające i niebezpieczne kody. eval użytkowanie, zanieczyszczenie prototypów i niebezpieczne konfiguracje Express.js — wzorce, które kompilują się poprawnie, ale wprowadzają podatne na wykorzystanie luki w zabezpieczeniach.
jamla
# 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 uzupełnia ESLint, a nie z nim konkuruje. ESLint egzekwuje konwencje; Semgrep wykrywa antywzorce bezpieczeństwa. Większość zespołów TypeScript dbających o bezpieczeństwo powinna korzystać z obu.
Kod Snyk: SAST oparty na uczeniu maszynowym z integracją IDE
Snyk Code wykonuje analizę SAST za pomocą silnika analitycznego opartego na uczeniu maszynowym, który śledzi przepływy zanieczyszczeń w plikach. Integruje się z VS Code i środowiskami IDE JetBrains, udostępniając wyniki w trakcie pisania kodu przez programistów, bez konieczności oczekiwania na uruchomienie ciągłej integracji (CI).
bash
npm install --save-dev snyk
npx snyk auth
npx snyk code testSkoncentrowanie się na doświadczeniu programistów, wbudowane informacje zwrotne dotyczące środowiska IDE, sugestie poprawek przy każdym znalezisku oraz przykłady napraw sprawiają, że Snyk Code jest lepszym wyborem w sytuacjach, gdy edukacja w zakresie bezpieczeństwa jest równie ważna, co wykrywanie zagrożeń.
SonarQube i SonarLint: Bramki jakości i śledzenie trendów
SonarQube zapewnia ciągłą analizę jakości kodu z panelem sterowania, śledzeniem trendów i dekoracją pull requestów. W przypadku TypeScript wykrywa błędy, smrody kodu, hotspoty bezpieczeństwa i duplikaty. SonarLint to rozszerzenie IDE, które lokalnie wyświetla reguły SonarQube.
Dla zespołów TypeScript prostszym rozwiązaniem jest SonarCloud (wersja hostowana w chmurze): jest bezpłatna w przypadku repozytoriów publicznych, a integracja CI odbywa się w ciągu kilku minut za pośrednictwem GitHub Actions lub GitLab CI.
jamla
# .github/workflows/sonar.yml
- name: SonarCloud Scan
uses: SonarSource/sonarcloud-github-action@master
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}Podstawową zaletą SonarQube w porównaniu z surowym lintingiem jest model trendów: jak zmienia się jakość kodu w czasie, które komponenty się pogarszają i jaki jest nowy wynik kontroli jakości kodu dla każdego pull requesta. Te metryki, dostępne dla kadry zarządzającej, to właśnie SonarQube oferuje, czego nie potrafią ESLint i Semgrep.
Warstwa 4: Analiza architektoniczna
Dependency-Cruiser: Wymuszanie reguł granicznych modułu
Dependency-Cruiser weryfikuje, czy graf importu spełnia zdefiniowane reguły architektoniczne. Generuje wizualne grafy zależności i nie zatwierdza ciągłej integracji (CI), gdy kod narusza ograniczenia dotyczące granic modułu.
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 bezpośrednio odpowiada na zapytania „react dependency analysis cli tool” w danych Search Console. Jest to standardowe narzędzie do generowania i sprawdzania poprawności grafów zależności w projektach TypeScript/React.
Deptrac: Egzekwowanie granic oparte na warstwach
Deptrac wymusza stosowanie warstw architektonicznych, zapewniając, że kod trwałości nie może importować się z prezentacji, obiekty domeny nie są zależne od infrastruktury oraz że granice modułów są respektowane w całej bazie kodu.
jamla
# 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 sprawdza się najlepiej w projektach realizowanych zgodnie ze wzorcami Clean Architecture, DDD lub Hexagonal Architecture, w których izolacja warstw jest ograniczeniem projektowym, a nie tylko preferencją.
Nx: Zarządzanie zależnościami na poziomie monorepozytorium
W przypadku monorepozytoriów TypeScript Nx umożliwia wymuszanie granic modułów, wykrywanie problemów z kompilacją i wizualizację grafu zależności we wszystkich projektach w repozytorium.
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-y affected polecenia uruchamiają tylko testy i linting odnoszące się do zmienionych modułów, co znacznie skraca czas ciągłej integracji (CI) w dużych monorepozytoriach.
Warstwa 5: Wykrywanie martwego kodu
Knip: Znajdź nieużywane eksporty, pliki i zależności
Knip analizuje cały wykres modułu, aby zidentyfikować nieużywane eksporty, nieużywane pliki i nieużywane package.json zależności, klasa akumulacji kodu, którą ESLint no-unused-vars nie można tego złapać, ponieważ przegląda tylko plik.
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 jest bezpośrednio wyszukiwany w danych SC jako „dead code detection unused exports javascript typescript”. Jest to obecnie najbardziej skuteczne narzędzie do identyfikacji martwego kodu na poziomie modułu w projektach TypeScript.
Warstwa 6: Analiza programowa, ts-morph
ts-morph to wrapper API kompilatora TypeScript, który ułatwia pisanie niestandardowych analiz, modyfikacji kodu i narzędzi dla AST TypeScript. Jest on wyszukiwany bezpośrednio w danych SC jako „ts-morph” i „ts morph”.
maszynopis
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 nie jest gotowym do uruchomienia narzędziem analitycznym, lecz biblioteką, której używa się do jego zbudowania. Jest odpowiedni dla zespołów, które potrzebują niestandardowej analizy wykraczającej poza możliwości istniejących narzędzi: skryptów migracyjnych, niestandardowych walidatorów architektury, automatycznego refaktoryzowania lub potoków generowania kodu.
Analiza statyczna TypeScript Async/Await
Dane Search Console pokazują konkretny klaster zapytań dotyczących „narzędzia TypeScript Static Analysis Async Await Paper Tool” i „narzędzia TypeScript Static Analysis Async Await Vulnerability Paper Tool”. Odzwierciedlają one praktyki poszukujące narzędzi, które rozumieją błędy programowania asynchronicznego na poziomie typu.
Praktycznym rozwiązaniem dla zespołów produkcyjnych TypeScript są cztery specyficzne dla asynchronii reguły TypeScript-eslint (no-floating-promises, await-thenable, no-misused-promises, require-await) w połączeniu z strictNullChecks oraz useUnknownInCatchVariablesRazem pozwalają one na wyłapywanie najczęstszych błędów asynchronicznych bez konieczności stosowania narzędzi badawczych.
Dla zespołów badających bezpieczeństwo wzorców podatności na ataki asynchroniczne TAJS i Jelly to akademickie analizatory statyczne, które modelują semantykę asynchronicznego wykonywania kodu JavaScript. Są to jednak narzędzia badawcze, a nie narzędzia do rozwoju produkcji.
Angular i React: analiza statyczna specyficzna dla frameworka
Dla zespołów Angular, @angular-eslint Zawiera specyficzne dla Angulara reguły lintingu, obejmujące wzorce komponentów, analizę szablonów i wstrzykiwanie usług. Integruje się z powyższą konfiguracją ESLint + typescript-eslint.
Dla zespołów ReactThe eslint-plugin-react, eslint-plugin-react-hooks, eslint-plugin-jsx-a11y Wtyczki obejmują wzorce specyficzne dla Reacta. Dependency-Cruiser obsługuje analizę grafu zależności specyficznego dla Reacta i jest narzędziem obsługującym zapytania „react dependency analysis cli tool” w danych SC.
Integracja IDE: narzędzia dla VS Code i JetBrains
Zapytania „najlepsze narzędzia do jakości kodu dla integracji z VS Code” i „najlepsze narzędzia do jakości kodu dla integracji ze środowiskiem IDE” odzwierciedlają realną potrzebę: informacje zwrotne dotyczące ciągłej integracji docierają zbyt późno, aby zmienić zachowanie. Analiza zintegrowana ze środowiskiem IDE zapewnia najściślejszą pętlę sprzężenia zwrotnego.
VS Code : rozszerzenie ESLint z funkcją Clippy Parity narzędzia rust-analyzer, rozszerzenie SonarLint dla wbudowanych reguł SonarQube, rozszerzenie Snyk dla wyników zabezpieczeń i wbudowana usługa języka TypeScript dla informacji zwrotnych na poziomie typu.
JetBrains (WebStorm/IntelliJ) : WebStorm oferuje wbudowaną obsługę języka TypeScript, która wykrywa błędy typu bezpośrednio w kodzie, a także integrację z ESLint, Prettier i SonarLint. Wbudowany system inspekcji obejmuje wiele wzorców, które są zgodne z regułami ESLint.
Konfiguracja VS Code zapewniająca maksymalny zasięg analizy statycznej języka TypeScript :
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"
}
}W jaki sposób SMART TS XL Rozszerza analizę języka TypeScript na całe przedsiębiorstwo
Powyższe narzędzia obejmują język TypeScript w ramach projektu TypeScript. W organizacjach, w których usługi TypeScript współdziałają z programami wsadowymi COBOL, interfejsami API Java, potokami danych Python lub starszymi systemami mainframe, narzędzia jednojęzyczne nie są w stanie dostrzec zależności wykraczających poza granice językowe.
SMART TS XL'S statyczna analiza kodu Obejmuje TypeScript wraz z każdym innym językiem w środowisku korporacyjnym, COBOL, JCL, Java, Python, RPG, SQL, i buduje ujednolicony model zależności dla wszystkich z nich. Gdy usługa TypeScript wywołuje API obsługiwane przez program COBOL, SMART TS XL można prześledzić tę relację i uwzględnić ją w analiza wpływu przed wprowadzeniem jakiejkolwiek zmiany w którymkolwiek z komponentów.
Funkcja wyszukiwania korporacyjnego sprawia , że cała wielojęzyczna baza kodu jest przeszukiwalna: możesz w ciągu kilku sekund znaleźć każdy import TypeScript określonego modułu, każdą metodę Java wywoływaną przez usługę TypeScript, każdy copybook COBOL przesyłający dane do interfejsu API obsługiwanego przez TypeScript, w milionach wierszy kodu w dowolnej kombinacji języków.
W przypadku zespołów korporacyjnych, które wykorzystują TypeScript jako jeden język w większym portfolio, SMART TS XL zapewnia widoczność architektoniczną i wielojęzyczność mapowanie zależności co sprawia, że narzędzia specyficzne dla TypeScript analizują swoją część systemu, SMART TS XL widzi całość.
Budowanie właściwego stosu
Nie ma jednego narzędzia obejmującego wszystkie aspekty jakości języka TypeScript. Właściwe podejście jest wielowarstwowe, a każda warstwa ukierunkowana jest na odrębną klasę problemów:
Minimalny stos wykonalny (nowy projekt, mały zespół):
- Tryb ścisły TypeScript
- ESLint z regułami asynchronicznymi TypeScript-Eslint
npm auditpod kątem luk w zabezpieczeniach zależności
Stos aplikacji produkcyjnych (zespół średniej wielkości, dbający o bezpieczeństwo):
- Wszystko powyżej oraz:
- Biome lub Prettier do formatowania
- Semgrep dla bezpieczeństwa SAST
- Knip dla martwego kodu
- SonarCloud zapewnia widoczność trendów wysokiej jakości
Stos Enterprise/monorepozytorium (duży zespół, ograniczenia architektoniczne):
- Wszystko powyżej oraz:
- Dependency-Cruiser do egzekwowania granic modułów
- Nx dla optymalizacji kompilacji w przypadku problemów z monorepozytorium
- Deptrac do walidacji granic warstw
- SonarQube (samodzielnie hostowany) do bram jakościowych na miejscu
Wielojęzyczny stos korporacyjny (TypeScript obok starszych systemów):
- Wszystko powyżej oraz:
- SMART TS XL do analizy wpływu międzyjęzykowego i mapowania zależności
