מערכת הטיפוסים של TypeScript לוכדת מחלקה משמעותית של באגים לפני הרצת קוד, אי התאמות בטיפוסים, מאפיינים חסרים, חתימות פונקציה שגויות. מה שהיא לא יכולה לתפוס הוא כל השאר: פגיעויות אבטחה שתלויות באופן שבו נתונים זורמים דרך האפליקציה, הפרות ארכיטקטוניות שמצטברות לאורך זמן ככל שגבולות הצוות מיטשטשים, יצוא מת שנשאר בבסיס הקוד זמן רב לאחר שהקוראים להם הוסרו, ושגיאות תכנות אסינכרוניות שמתקמפלות כהלכה אך נכשלות בתנאי זמן ריצה ספציפיים. כלי ניתוח סטטיים ממלאים את הפערים הללו, ובחירת השילוב הנכון תלויה במה שאתם באמת מנסים למצוא.
מדריך זה מכסה את הכלים החשובים לצוותי TypeScript בשנת 2026: שכבת ה-linting (ESLint עם typescript-eslint, Biome, OxcLint), שכבת האבטחה (Semgrep, Snyk Code, SonarQube), שכבת האדריכלות (Dependency-Cruiser, Deptrac, Nx), שכבת ה-dead code (Knip) ושכבת הניתוח העמוק (ts-morph, מהדר TypeScript עצמו). עבור כל אחד מהם, הדגש הוא על מה שהוא עושה בפועל, כיצד להגדיר אותו, ומתי הוא אינו הכלי המתאים למשימה.
נבנה עבור בסיסי קוד שאף אחד לא מבין
SMART TS XL מצייר באופן אוטומטי שינויים שבירים בכל בסיס הקוד שלך.
למד עודכלי ניתוח סטטי של TypeScript: טבלת השוואה
לפני שנצלול לכלים בודדים, הטבלה שלהלן ממפה כל כלי לתפקודו העיקרי, התאמתו ל-CI ולמקרה השימוש האידיאלי שלו. אין כלי בודד המכסה את כל הממדים, ניתוח איכות יעיל של TypeScript דורש שכבות של כמה.
| כלי | פונקציה ראשית | מתאים ל-CI | עלות | הכי טוב |
|---|---|---|---|---|
| ESLint + typescript-eslint | לינטיישן, סגנון, כללי מודעות לסוג | יש | חופשי | מוסכמות כלל-צוותיות, בטיחות מסוג אסינכרוני |
| ביומה | לינטינג + עיצוב | יש | חופשי | ESLint + תחליף יפה יותר, מהירות |
| אוקסלינט | לינטי (תואם ל-ESLint) | יש | חופשי | מונורפוס זקוק לזמני סיבים מהירים |
| מהדר TypeScript (tsc) | סוג בדיקה | יש | חופשי | שגיאות הקלדה, אכיפה קפדנית של מצב |
| Semgrep | SAST, תבניות מותאמות אישית | יש | חינם + בתשלום | סריקת אבטחה, כללי ארגון מותאמים אישית |
| קוד סניק | SAST, אבטחת תלות | יש | חינם + בתשלום | צוותי אבטחה במקום הראשון, שילוב IDE |
| סונאר קיוב / סונאר קלאוד | שערי איכות, מעקב אחר מגמות | יש | חינם + בתשלום | לוחות מחוונים לאיכות ארגונית |
| סונארלינט | משוב איכותי ברמת IDE | IDE בלבד | חופשי | רמזים מובנים לאבטחה ואיכות |
| ספינת תלויות | אכיפת גרף תלות | יש | חופשי | אימות כללים אדריכליים |
| דפטרק | אכיפת גבולות שכבות | יש | חופשי | ארכיטקטורה נקייה, גבולות DDD |
| Nx | ניהול תלות מונורפו | יש | חינם + בתשלום | גבולות מודול Monorepo |
| גזירה | קוד מת ויצוא שאינו בשימוש | יש | חופשי | צמצום קוד שאינו בשימוש בקנה מידה גדול |
| ts-מורף | ניתוח TS פרוגרמטי AST | סלקטיבי | חופשי | ניתוח מותאם אישית, קודמודים, כלי עבודה |
שכבה 1: סיבים וסגנון
ESLint עם typescript-eslint
ESLint נשאר הבסיס של יצירת פתרונות ליצירת פתרונות ל-TypeScript. עם ה- typescript-eslint בחבילה, היא מקבלת גישה למידע הסוג של TypeScript ויכולה לאכוף כללים הדורשים הקשר סוגים, כאשר החשובים שבהם הם הכללים הספציפיים לאסינכרוניים שתופסים טעויות נפוצות של Promise.
לחבוט
npm install --save-dev typescript-eslint
JavaScript
// 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",
},
}
);
ארבעת הכללים האסינכרוניים לעיל הם התוספת בעלת הערך הגבוה ביותר ש-typescript-eslint מספק על פני ESLint רגיל. הם תופסים: הבטחות לא מטופלות (הבטחות צפות), await מוחל על ערכים שאינם Promise, Promises המועברים לקריאות חוזרות המצפות לפונקציות סינכרוניות, ופונקציות אסינכרוניות שלעולם לא משתמשות awaitאלו הן תבניות שמתקמפלות בצורה נקייה אך מייצרות כשלים בזמן ריצה בתנאים ספציפיים.
מה ש-ESLint לא יכולה לעשותניתוח זרימת נתונים בין קבצים, אכיפת גבולות אדריכליים, מעקב אחר כתמי אבטחה או זיהוי ייצוא מת. עבור אלה, נדרשות השכבות האחרות שלהלן.
ביומה: ESLint המודרני + תחליף יפה יותר
Biome מחליף גם את ESLint וגם את Prettier בקובץ בינארי יחיד מבוסס Rust שפועל מהר יותר פי 25-35. הוא תומך ב-JavaScript, TypeScript, JSX ו-JSON. עבור פרויקטים חדשים או צוותים המתוסכלים ממורכבות התוספים של ESLint וביצועים איטיים בבסיסי קוד גדולים, Biome היא האלטרנטיבה המודרנית החזקה ביותר.
לחבוט
npm install --save-dev --save-exact @biomejs/biome
npx @biomejs/biome init
לחבוט
# 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/
מערכת התוספים של Biome קטנה יותר מזו של ESLint, דבר שחשוב לצוותים עם כללים מותאמים אישית נרחבים או תוספים ספציפיים למסגרת. עבור צוותים המשתמשים רק בכללי הליבה של ESLint ובעיצוב Prettier, Biome מספק כיסוי שווה ערך בחלקיק מזמן הביצוע.
OxcLint: תאימות ESLint עם מהירות ראשונה
OxcLint (חלק מפרויקט Oxc) מריץ כללים תואמי ESLint במהירות ביצוע מהירה פי 50-100. הוא אינו מחליף את המערכת האקולוגית המלאה של ESLint, אך משמש כאפשרות המהירה ביותר עבור צינורות CI שבהם זמן ה-lint הוא צוואר בקבוק.
לחבוט
npm install --save-dev oxlint
npx oxlint src/
OxcLint היא הבחירה הנכונה עבור מונורפו גדולים שבהם ESLint סטנדרטי לוקח דקות ספורות והשהיית לולאת המשוב מפחיתה את איכות בקשת ה-pull. הוא עובד בצורה הטובה ביותר לצד ESLint במקום להחליף אותו, הפעל את OxcLint עבור נתיב המשוב המהיר ואת ESLint עבור כיסוי מלא של הכללים בשער טרום-המיזוג.
שכבה 2: בדיקת סוגים, מהדר TypeScript
מהדר TypeScript (tsc) אינו רק כלי בנייה, זהו מנוע הניתוח הסטטי העיקרי לתקינות ברמת הסוג. הפעלת מצב strict מפעילה את ההגדרות שתופסות את רוב הבאגים בעולם האמיתי:
ג'סון
{
"compilerOptions": {
"strict": true,
"noUnusedLocals": true,
"noUnusedParameters": true,
"noImplicitReturns": true,
"noFallthroughCasesInSwitch": true,
"exactOptionalPropertyTypes": true,
"useUnknownInCatchVariables": true
}
}
לחבוט
# Type-check only, no emit -- ideal for CI
npx tsc --noEmit
noUnusedLocals ו noUnusedParameters ברמת המהדר, לתפוס משתנים ופרמטרי פונקציה שאינם בשימוש. useUnknownInCatchVariables (סוגי TypeScript 4.4+) נתפסו חריגים כ unknown ולא any, כופה צמצום סוגים מפורש לפני השימוש.
ניתוח זרימת בקרה של TypeScript היא יכולת מובנית שהמהדר מספק לצמצום סוגים בתוך ענפים מותנים. זה לא כלי נפרד, המאפשר strict מצב מבטיח שהוא מיושם בקפדנות מלאה. ניתוח זרימת הבקרה של המהדר מבין סוגים מגנים, typeof צ'קים, instanceof, ודפוסי איגודים מקצועיים מפלים.
מגבלת ה-TSCמהדר TypeScript אינו מוצא פגיעויות אבטחה, הפרות גבולות אדריכליים או יצוא לא פעיל. הוא מוצא שגיאות הקלדה, והוא עושה זאת באופן חד משמעי.
שכבה 3: אבטחה, SAST עבור TypeScript
Semgrep: סריקת אבטחה מבוססת תבניות
Semgrep מוצאת פגיעויות אבטחה באמצעות התאמת תבניות קוד. עבור TypeScript, הוא יכול לזהות הזרקת SQL, XSS, אישורים מקודדים, אובייקטים לא בטוחים. eval שימוש, זיהום אב טיפוס ותצורות Express.js לא מאובטחות, תבניות שמתקמפלות כהלכה אך מציגות פגיעויות הניתנות לניצול.
יאמל
# 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: ERROR
לחבוט
# Run with the community TypeScript security rules
semgrep scan --config=p/typescript --config=p/owasp-top-ten src/
Semgrep משלים את ESLint, לא מתחרה איתו. ESLint אוכף מוסכמות; Semgrep מוצא תבניות אנטי-אבטחה. רוב צוותי TypeScript שאכפת להם מאבטחה צריכים להריץ את שניהם.
קוד Snyk: SAST מבוסס ML עם שילוב IDE
Snyk Code מבצעת SAST עם מנוע ניתוח מבוסס למידת מכונה שעוקב אחר זרימות זיהום בין קבצים. היא משתלבת ב-VS Code וב-JetBrains IDEs, וחושפת ממצאים באופן מקוון כאשר מפתחים כותבים קוד במקום להמתין להרצת CI.
לחבוט
npm install --save-dev snyk
npx snyk auth
npx snyk code test
המיקוד של Snyk Code בחוויית המפתחים, משוב מובנה על IDE, הצעות תיקונים לצד כל ממצא ודוגמאות לתיקון, הופכים אותו לבחירה טובה יותר כאשר חינוך לאבטחה חשוב לא פחות מגילוי אבטחה.
SonarQube ו-SonarLint: שערי איכות ומעקב אחר מגמות
SonarQube מספק ניתוח רציף של איכות הקוד באמצעות לוח מחוונים, מעקב אחר מגמות וקישוט בקשות משיכה. עבור TypeScript, הוא מזהה באגים, ריחות קוד, נקודות חמות של אבטחה וכפילויות. SonarLint היא הרחבת IDE שחושפת את כללי SonarQube באופן מקומי.
עבור צוותי TypeScript, SonarCloud (הגרסה המאוחסנת בענן) היא הנתיב הפשוט יותר: חינמי עבור מאגרים ציבוריים, עם שילוב CI דרך GitHub Actions או GitLab CI תוך דקות.
יאמל
# .github/workflows/sonar.yml
- name: SonarCloud Scan
uses: SonarSource/sonarcloud-github-action@master
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
הערך העיקרי של SonarQube על פני עיבוד שבבי גולמיים (raw linting) הוא מודל המגמה שלו: כיצד איכות הקוד מתפתחת לאורך זמן, אילו רכיבים מתדרדרים, ומהו ציון שער האיכות של קוד חדש עבור כל בקשת משיכה. מדדים אלה הפונים לניהול הם מה ש-SonarQube עושה ש-ESLint ו-Semgrep לא יכולים לעשות.
שכבה 4: ניתוח אדריכלי
Dependency-Cruiser: אכיפת כללי גבול מודול
Dependency-Cruiser מאמת שהגרף המיובאי שלך עומד בכללים ארכיטקטוניים מוגדרים. הוא מייצר גרפי תלות חזותיים ומכשל ב-CI כאשר הקוד מפר את אילוצי גבולות המודול.
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))" },
},
],
};
לחבוט
npx depcruise --validate .dependency-cruiser.cjs src/
Dependency-Cruiser מטפל ישירות בשאילתות "react dependency analysis cli tool" בנתוני Search Console, זהו הכלי הסטנדרטי ליצירה ואימות של גרפי תלות בפרויקטים של TypeScript/React.
דפטרק: אכיפת גבולות מבוססת שכבות
Deptrac אוכף שכבות אדריכליות, ומבטיח שקוד persistence לא יוכל לייבא מהמצגת, שאובייקטי תחום אינם תלויים בתשתית, ושגבולות המודולים מכובדים לאורך כל בסיס הקוד.
יאמל
# 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
- Domain
Deptrac הוא בעל ערך רב ביותר בפרויקטים העוקבים אחר תבניות של ארכיטקטורה נקייה, DDD או ארכיטקטורה משושה, שבהן בידוד שכבות הוא אילוץ עיצובי, לא רק העדפה.
Nx: ניהול תלות ברמת Monorepo
עבור מונו-רפואים של TypeScript, Nx מספקת אכיפת גבולות מודולים, זיהוי בנייה מושפעת, והדמיה של גרף תלויות בכל הפרויקטים במאגר.
ג'סון
// .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 פקודות מריצות רק את הבדיקות וה-linting הרלוונטיים למודולים שהשתנו, מה שמפחית משמעותית את זמן ה-CI במונורפו גדולים.
שכבה 5: זיהוי קוד מת
Knip: מצא קבצי ייצוא, קבצים ותלויות שאינם בשימוש
Knip מנתח את גרף המודול המלא כדי לזהות ייצוא שאינו בשימוש, קבצים שאינם בשימוש וקבצים שאינם בשימוש package.json תלויות, סוג צבירת הקוד ש-ESLint no-unused-vars לא יכול לתפוס כי זה מחפש רק בתוך קובץ.
לחבוט
npm install --save-dev knip
npx knip
ג'סון
// knip.json
{
"entry": ["src/index.ts", "src/**/*.test.ts"],
"project": ["src/**/*.ts"],
"ignore": ["src/generated/**"],
"ignoreDependencies": ["vitest"]
}
Knip מתבצע ישירות בנתוני SC בתור "dead code detection unused exports javascript typescript". זהו הכלי היעיל ביותר כיום לזיהוי קוד מת ברמת המודול בפרויקטים של TypeScript.
שכבה 6: ניתוח פרוגרמטי, ts-morph
ts-morph הוא עטיפת API של מהדר TypeScript המאפשרת כתיבת ניתוחים מותאמים אישית, קודמודים וכלים כנגד AST של TypeScript. הוא מחפש ישירות בנתוני SC כ-"ts-morph" ו-"ts morph".
כתב כתיבה
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 אינו כלי ניתוח מוכן להפעלה, אלא הספרייה שבה משתמשים כדי לבנות אחד. הוא מתאים לצוותים הזקוקים לניתוח מותאם אישית מעבר למה שהכלים הקיימים תומכים בו: סקריפטים של הגירה, מאמתים ארכיטקטוניים מותאמים אישית, שיפוץ אוטומטי או צינורות יצירת קוד.
ניתוח סטטי אסינכרוני/המתנה של TypeScript
נתוני Search Console מציגים אשכול ספציפי של שאילתות סביב "typescript static analysis async await paper tool" ו-"typescript static analysis async await vulnerability paper tool". אלה משקפים מומחים המחפשים כלים שמבינים שגיאות תכנות אסינכרוניות ברמת הסוג.
התשובה המעשית עבור צוותי TypeScript בייצור היא ארבעת הכללים הספציפיים לאסינכרוניים של typescript-eslint (no-floating-promises, await-thenable, no-misused-promises, require-await) בשילוב עם strictNullChecks ו useUnknownInCatchVariablesיחד, אלה לוכדים את שגיאות האסינכרוניות הנפוצות ביותר מבלי להזדקק לכלי מחקר אקדמיים.
עבור צוותים שעוסקים במחקר אבטחה על דפוסי פגיעויות אסינכרוניות, TAJS ו-Jelly הם מנתחים סטטיים אקדמיים המדגמים את הסמנטיקה של ביצוע אסינכרוני של JavaScript, אך הם כלי מחקר, לא כלי פיתוח ייצור.
Angular ו-React: ניתוח סטטי ספציפי למסגרת
עבור צוותי אנגולר, @angular-eslint מספק כללי linting ספציפיים ל-Angular המכסים תבניות רכיבים, ניתוח תבניות והזרקת שירותים. הוא משתלב עם תצורת ESLint + typescript-eslint לעיל.
עבור צוותי ריאקט, ה eslint-plugin-react, eslint-plugin-react-hooks, ו eslint-plugin-jsx-a11y תוספים מכסים תבניות ספציפיות ל-React. Dependency-Cruiser מטפל בניתוח גרפי תלויות ספציפיים ל-React והוא הכלי שעומד מאחורי שאילתות "react dependency analysis cli tool" בנתוני SC.
שילוב IDE: כלים עבור VS Code ו-JetBrains
השאילתות "כלי קוד איכותיים לשילוב VS Code" ו"כלי קוד איכותיים לשילוב IDE" משקפות צורך אמיתי: משוב CI מגיע מאוחר מדי כדי לשנות התנהגות. ניתוח משולב IDE מספק את לולאת המשוב ההדוקה ביותר.
קוד VSהרחבת ESLint עם מנתח חלודה Clippy parity, הרחבת SonarLint עבור כללי SonarQube מוטבעים, הרחבת Snyk עבור ממצאי אבטחה, ושירות שפת TypeScript מובנה עבור משוב ברמת הסוג.
JetBrains (WebStorm/IntelliJ)WebStorm מגיע עם תמיכה מובנית ב-TypeScript שחושפת שגיאות הקלדה באופן מקוון, בנוסף לאינטגרציה עם ESLint, Prettier ו-SonarLint. מערכת הבדיקה המובנית מכסה רבות מאותן תבניות כמו כללי ESLint.
תצורת VS Code לכיסוי ניתוח סטטי מקסימלי של TypeScript:
ג'סון
// .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"
}
}
איך SMART TS XL מרחיב את ניתוח TypeScript ברחבי הארגון
הכלים הנ"ל מכסים את TypeScript בתוך פרויקט TypeScript. בארגונים שבהם שירותי TypeScript מקיימים אינטראקציה עם תוכניות אצווה של COBOL, ממשקי API של Java, צינורות נתונים של Python או מערכות מיינפריים מדור קודם, כלים בשפה אחת אינם יכולים לראות את התלויות החוצות גבולות שפה.
SMART TS XL"S ניתוח קוד סטטי מכסה את TypeScript לצד כל שפה אחרת בסביבת הארגון, COBOL, JCL, Java, Python, RPG, SQL, ובונה מודל תלות מאוחד על פני כולן. כאשר שירות TypeScript קורא ל-API המגובה על ידי תוכנית COBOL, SMART TS XL יכול לעקוב אחר הקשר הזה ולכלול אותו ב ניתוח השפעות לפני ביצוע כל שינוי באחד הרכיבים.
השמיים חיפוש ארגוני היכולת הופכת את כל בסיס הקוד הרב-לשוני לניתן לשאילתה: מצא כל ייבוא TypeScript של מודול ספציפי, כל שיטת Java ששירות TypeScript קורא לה, כל ספר עותקים של COBOL שמזין נתונים ל-API הנצרך על ידי TypeScript, תוך שניות, על פני מיליוני שורות קוד בכל שילוב של שפות.
עבור צוותי ארגון המפעילים את TypeScript כשפה אחת בתוך תיק עבודות גדול יותר, SMART TS XL מספק את הנראות האדריכלית ואת הגישה החוצה לשונית מיפוי תלות שגורם לכלי TypeScript ספציפיים להסתכל על החלק שלהם במערכת בזמן SMART TS XL רואה את השלם.
בניית הערימה הנכונה
אין כלי יחיד המכסה את כל ממדי האיכות עבור TypeScript. הגישה הנכונה היא גישה רב-שכבתית, כאשר כל שכבה מכוונת לסוג בעיה נפרד:
מחסנית מינימלית בת קיימא (פרויקט חדש, צוות קטן):
- מצב קפדני של TypeScript
- ESLint עם כללי אסינכרון של typescript-eslint
npm auditעבור פגיעויות תלות
מחסנית יישומי ייצור (צוות בינוני, מודע לאבטחה):
- הכל למעלה, פלוס:
- ביומה או יפה יותר לעיצוב
- Semgrep עבור SAST אבטחה
- סכין לקוד מת
- SonarCloud לנראות מגמות איכותית
מחסנית ארגונית / מונורפו (צוות גדול, אילוצים אדריכליים):
- הכל למעלה, פלוס:
- Dependency-Cruiser לאכיפת גבולות מודולים
- Nx עבור אופטימיזציה של בניית מושפעת ממונו-רפו
- Deptrac לאימות גבולות שכבה
- SonarQube (אחסון עצמי) לשערים איכותיים באתר
מחסנית ארגונית של פוליגלוט (TypeScript לצד מערכות מדור קודם):
- הכל למעלה, פלוס:
- SMART TS XL לניתוח השפעות חוצות-לשונות ומיפוי תלות