Dasturlash kitobi (eski nashr)/15-QISM — Kasbiy konikmalar3/8-dars42 daqiqa

Mundarija (30)

1. Kirish va motivatsiya
2. Nazariya — chuqur tushuntirish
2.1. Nega avtomatlashtirish (vositalar roli)
2.2. ESLint (kod sifati)
2.3. Prettier (format)
2.4. Husky (git hooks)
2.5. lint-staged (faqat o'zgargan)
2.6. CI'da va to'liq sozlash
2.7. Best practices va keng muammolar
2.8. Performans (kesh), jamoa uchun umumiy konfiguratsiya va monorepo
2.9. Qachon qaysi qoida to'plami (Airbnb / Standard / o'z)
3. Sintaksis — sozlash ma'lumotnoma
4. Batafsil misollar
Misol 1 — ESLint sozlash (2.2)
Misol 2 — Prettier + ESLint birga (2.3)
Misol 3 — Husky + lint-staged (2.4, 2.5)
Misol 4 — To'liq CI sozlash (2.6)
Misol 5 — eslint-disable to'g'ri ishlatish (2.7)
Misol 6 — React plaginlari va flat config (2.2.2)
5. To'g'ri va noto'g'ri holatlar
6. Keng tarqalgan xatolar va yechimlari
7. Integratsiya — bu mavzu stack'ning qayerida uchraydi
8. Eng yaxshi amaliyotlar (best practices)
9. Amaliy loyiha: "Kod Sifati Avtomatlashtirish"
Maqsad
Talablar (requirements)
Maslahatlar (hint)
"Tayyor" mezonlari (acceptance criteria)
10. Xulosa va keyingi bobga ko'prik
Foydalanilgan rasmiy/ishonchli manbalar

ESLint, Prettier, Husky va lint-staged — kod sifatini avtomatlashtirish (15.3-bob)

15-QISM — Kasbiy ko'nikmalar · 3-mavzu

1. Kirish va motivatsiya

15.1 va 15.2-boblarda toza kod va code review'ni o'rgandik. Lekin ikki savol qoldi: (1) kod uslubini (format, qoidalar) qo'lda izchil tutib bo'lmaydi (har dasturchi boshqacha yozadi — bo'shliq, qator, tirnoq — chalkash); (2) code review'da odam format/uslubga vaqt sarflamasligi kerak (15.2: 2.7 — mashina qiladi). Yechim — avtomatlashtirish: bu bobda kod sifatini avtomatik, izchil qiladigan to'rt vositani ko'ramiz: ESLint (kod sifati/xatolar — statik tahlil), Prettier (avtomatik format), Husky (git hooks — commit'dan oldin tekshiruv), lint-staged (faqat o'zgargan fayllar — tez).

Bu vositalar professional standart (deyarli har zamonaviy JS/TS loyihada). Ular nima beradi: (1) izchil format (Prettier — har fayl bir xil — bo'shliq/qator munozarasi yo'q); (2) xato/yomon naqsh oldini (ESLint — == o'rniga ===, ishlatilmagan o'zgaruvchi, xavfli kod — kod yozish paytida ogohlantiradi); (3) avtomatik tekshiruv (Husky — har commit'dan oldin lint/format — buzuq kod git'ga ketmaydi); (4) tezlik (lint-staged — faqat o'zgargan fayllarni tekshir — butun loyiha emas). Natijada: kod sifati avtomatik (qo'lda emas), izchil (har dasturchi bir xil), va review format munozarasidan ozod (odam mantiqqa — 15.2). Bu bob ularni sozlash va ishlatishni ko'rsatadi.

Bu bob to'rt vositani to'liq ochadi: nega avtomatlashtirish, ESLint (kod sifati — qoidalar, flat config, plaginlar, sozlash), Prettier (format — sozlash, .prettierignore, ESLint bilan integratsiya), TypeScript type-check (tsc --noEmit), Husky (git hooks — pre-commit/pre-push/commit-msg), lint-staged (faqat o'zgargan fayllar), commitlint (conventional commits), CI'da (PR'da lint/format/type/test), editor integratsiyasi (VS Code), jamoa uchun umumiy konfiguratsiya (shared config paket), performans (kesh) va qachon qaysi qoida (Airbnb/Standard/o'z).

O'xshatish: Bu vositalar — bu imlo tekshiruvchi va avtomatik formatlovchi (matn muharririda). Yozayotganingizda imlo tekshiruvchi (ESLint) xato so'zni qizil chizadi ("bu noto'g'ri — tuzat"), avtomatik formatlovchi (Prettier) matnni bir xil ko'rinishga keltiradi (sarlavhalar, abzaslar — izchil). Husky — bu "chop etishdan oldin tekshir" qoidasi (hujjatni saqlashdan oldin imlo/format avtomatik tekshiriladi — xato bilan saqlanmaydi). lint-staged — faqat o'zgartirgan abzaslarni tekshir (butun kitobni emas — tez). Bularsiz — har yozuvchi boshqacha formatda yozadi (chalkash), imlo xatolar o'tib ketadi; bular bilan — hamma matn izchil, toza, xatosiz (avtomatik — yozuvchi o'ylamaydi). Kod ham shunday: bu vositalar kod uslubini avtomatik izchil va toza qiladi (dasturchi format haqida o'ylamaydi — vositalar qiladi).

Nega muhim?

Izchillik — Prettier har faylni bir xil (bo'shliq/qator munozarasi yo'q — vaqt tejash).
Xato oldini — ESLint xato/yomon naqshni yozish paytida topadi (production'dan oldin).
Avtomatik — Husky har commit'da tekshir (qo'lda emas — unutilmaydi).
Review tejash — format avtomatik → odam mantiqqa (15.2: 2.7).

2. Nazariya — chuqur tushuntirish

2.1. Nega avtomatlashtirish (vositalar roli)

text

  TO'RT VOSITA — har biri o'z vazifasi (birga — kod sifati avtomatik):

  ┌──────────────┬────────────────────────────────────────────┐
  │ ESLint       │ Kod SIFATI/XATO (statik tahlil — qoidalar) │
  │              │ → ==/===, ishlatilmagan, xavfli, naqsh     │
  ├──────────────┼────────────────────────────────────────────┤
  │ Prettier     │ Kod FORMAT (avtomatik — bo'shliq/qator)    │
  │              │ → izchil ko'rinish (uslub munozarasiz)     │
  ├──────────────┼────────────────────────────────────────────┤
  │ Husky        │ GIT HOOKS (commit/push'dan oldin tekshir)  │
  │              │ → buzuq kod git'ga ketmaydi                │
  ├──────────────┼────────────────────────────────────────────┤
  │ lint-staged  │ Faqat O'ZGARGAN fayllar (tez)              │
  │              │ → butun loyiha emas — staged fayllar       │
  └──────────────┴────────────────────────────────────────────┘

  ESLint vs Prettier (chalkashtirma):
  → ESLint — KOD MANTIQ/SIFAT (xato, yomon naqsh — "=== ishlat")
  → Prettier — FORMAT (ko'rinish — "4 bo'shliq, qator uzunligi")

  ❗ ESLint (sifat/xato) + Prettier (format) + Husky (git hook) + lint-staged (tez)
  ❗ Birga — kod sifati AVTOMATIK, izchil (qo'lda emas — vositalar qiladi)

Nega avtomatlashtirish (vositalar roli) — to'rt vosita va ularning vazifalari. Kod sifatini avtomatik, izchil qilish uchun to'rt vosita (har biri o'z vazifasi): (1) ESLint — kod sifati/xato (statik tahlil — kodni ishga tushirmasdan tekshiradi — qoidalar bo'yicha: == o'rniga === ishlat, ishlatilmagan o'zgaruvchi, xavfli kod, yomon naqsh); (2) Prettier — kod format (avtomatik — bo'shliq, qator uzunligi, tirnoq, vergul — izchil ko'rinish — uslub munozarasiz); (3) Husky — git hooks (git hodisalarida — commit/push'dan oldin — avtomatik tekshiruv ishga tushadi — buzuq kod git'ga ketmaydi); (4) lint-staged — faqat o'zgargan (staged) fayllarni tekshir (butun loyiha emas — tez — faqat commit qilinayotgan fayllar). ESLint vs Prettier (ko'p chalkashtiriladi): ESLint — kod mantiq/sifat (xato, yomon naqsh — "=== ishlat", "bu o'zgaruvchi ishlatilmaydi"); Prettier — format (faqat ko'rinish — "4 bo'shliq, qator uzunligi 80" — mantiqga aralashmaydi). Ya'ni ESLint nima yomon (sifat), Prettier qanday ko'rinadi (format). Ikki nuqta: (1) ESLint (sifat/xato) + Prettier (format) + Husky (git hook) + lint-staged (tez) — har biri o'z vazifasi; (2) birga — kod sifati avtomatik, izchil (qo'lda emas — vositalar qiladi — dasturchi format/uslub haqida o'ylamaydi). Bu to'rt vosita — zamonaviy JS/TS loyiha standarti (deyarli har loyihada — create-next-app ham ESLint bilan keladi). Ularni tushunish va sozlash — professional dasturchining asosiy ko'nikmasi (kod sifatini avtomatlashtirish — qo'lda izchillikni tutib bo'lmaydi — vositalar kerak). Bu — 15.2: 2.7 (review avtomatlashtirish)ning amaliy qismi.

2.2. ESLint (kod sifati)

text

  ESLint — kodni STATIK tahlil qilib, XATO/yomon naqshni topadi:

  NIMA TOPADI:
  ✓ Potensial xato (ishlatilmagan o'zgaruvchi, yetib bo'lmaydigan kod)
  ✓ Yomon naqsh (== o'rniga ===, var o'rniga let/const)
  ✓ Xavfsizlik (eval, dangerouslySetInnerHTML — 14.2)
  ✓ Loyiha qoidalari (maxsus — masalan console.log taqiq)

  SOZLASH (eslint.config.js — flat config — yangi):
  import js from "@eslint/js";
  import tseslint from "typescript-eslint";
  export default [
    js.configs.recommended,           // standart qoidalar
    ...tseslint.configs.recommended,  // TypeScript qoidalari
    {
      rules: {
        "no-console": "warn",         // console.log — ogohlantirish
        "no-unused-vars": "error",    // ishlatilmagan — xato
        "eqeqeq": "error",            // === majburiy
      },
    },
  ];

  ISHLATISH:
  npx eslint .           // tekshir
  npx eslint . --fix     // avtomatik tuzatiladiganni tuzat

  ❗ ESLint — kod sifati/xato (statik tahlil — ===, ishlatilmagan, xavfli)
  ❗ Qoidalar sozlanadi (recommended + loyiha); --fix avtomatik tuzatadi

ESLint (kod sifati) — kodni statik tahlil qilib xato/yomon naqshni topish. ESLint — kodni statik (ishga tushirmasdan) tahlil qilib, muammolarni topadi. Nima topadi: (1) potensial xato (ishlatilmagan o'zgaruvchi — const x = 5 lekin x hech qaerda ishlatilmaydi — ehtimol unutilgan; yetib bo'lmaydigan kod — returndan keyin kod); (2) yomon naqsh (== o'rniga === — 2-QISM — tip xavfi; var o'rniga let/const); (3) xavfsizlik (eval, dangerouslySetInnerHTML — 14.2 — ogohlantiradi); (4) loyiha qoidalari (maxsus — masalan console.log taqiq — production'da qolmasin). Sozlash (eslint.config.js — flat config — yangi format): js.configs.recommended (standart qoidalar — eng keng) + tseslint.configs.recommended (TypeScript qoidalari — 7-QISM) + maxsus rules (no-console: "warn" — console ogohlantirish, no-unused-vars: "error" — ishlatilmagan xato, eqeqeq: "error" — === majburiy). Qoidalar darajalari: "off" (o'chiq), "warn" (ogohlantirish — sariq), "error" (xato — qizil — CI'ni yiqitadi). Ishlatish: npx eslint . (loyiha tekshir), npx eslint . --fix (avtomatik tuzatiladiganlarni tuzat — masalan ===). Ikki nuqta: (1) ESLint — kod sifati/xato (statik tahlil — ===, ishlatilmagan, xavfli kod, yomon naqsh); (2) qoidalar sozlanadi (recommended + loyiha maxsus), --fix avtomatik tuzatadi. ESLint — kod sifatining "qorovuli" (yomon naqsh, potensial xatoni yozish paytida — IDE'da qizil chiziq — ogohlantiradi — production'dan oldin). U mantiq/sifat (Prettier — format — 2.3). Editor (VS Code ESLint plugin) — yozayotganda real vaqtda ko'rsatadi (xato darrov ko'rinadi). recommended qoidalar — yaxshi boshlanish (keng tarqalgan muammolar), keyin loyihaga moslash (maxsus qoidalar). ESLint — har JS/TS loyihaning asosiy sifat vositasi.

2.2.1. Flat config (`eslint.config.js`) vs eski (`.eslintrc`)

ESLint sozlashning ikki formati bor va ularni ajratish muhim, chunki eski loyihalarda hali eski format uchraydi:

text

  ESKI FORMAT (.eslintrc.json / .eslintrc.js — ESLint 8 va oldin):
  {
    "env": { "browser": true, "es2021": true, "node": true },
    "parser": "@typescript-eslint/parser",
    "parserOptions": { "ecmaVersion": "latest", "sourceType": "module" },
    "extends": ["eslint:recommended", "plugin:@typescript-eslint/recommended"],
    "plugins": ["@typescript-eslint", "react", "import"],
    "rules": { "eqeqeq": "error" },
    "overrides": [ { "files": ["*.test.ts"], "rules": { "no-console": "off" } } ]
  }
  → alohida "env"/"extends"/"plugins"/"parser" maydonlari, "overrides" massivi

  YANGI FORMAT (eslint.config.js — flat config — ESLint 9 default):
  export default [
    { ...konfiguratsiya obyektlari massivi... }
  ]
  → oddiy JS massiv; "extends" o'rniga import + spread (...);
  → "env" o'rniga languageOptions.globals; "parser" languageOptions.parser;
  → "overrides" o'rniga alohida massiv elementi (files bilan filtrlash);
  → plaginlar import qilinadi (obyekt sifatida), string nomi emas

Nima farqi bor? Eski format (.eslintrc.*) — deklarativ maydonlar: env (global o'zgaruvchilar to'plami — browser, node), parser (kodni tahlil qiluvchi — TS uchun @typescript-eslint/parser), parserOptions, extends (tayyor konfiguratsiya ro'yxati — string), plugins (string nomlar), overrides (ma'lum fayllarga boshqa qoidalar). Yangi flat config (eslint.config.js) — bularning barchasi oddiy JS massiviga aylanadi: extends o'rniga siz konfiguratsiyani import qilib massivga qo'shasiz (...tseslint.configs.recommended), env o'rniga languageOptions.globals, parser o'rniga languageOptions.parser, overrides o'rniga faqat files maydoni bo'lgan alohida massiv elementi. Flat config afzalligi: aniqroq (JS — kalkulyatsiya, funksiya ishlatish mumkin), qatlamlanish tushunarli (massiv tartibi — keyingisi oldingisini ustidan yozadi). ESLint 9'dan boshlab flat config — standart; yangi loyihalarda faqat shuni ishlating, eski loyihada .eslintrc uchrasa migratsiya (ESLint migration guide) qiling.

2.2.2. Plaginlar — ekotizim qoidalari

ESLint yadrosida faqat umumiy JS qoidalari bor. Freymvork va texnologiya qoidalari plaginlar orqali keladi. Eng keng ishlatiladiganlar:

text

  KENG PLAGINLAR:
  @typescript-eslint  → TypeScript qoidalari (any, unused, tip xavfsizligi — 7-QISM)
  eslint-plugin-react + react-hooks → React qoidalari (hook qoidalari,
                        useEffect bog'liqlik massivi — 11-QISM)
  eslint-plugin-jsx-a11y → JSX qulaylik (a11y — alt matn, aria — 13-QISM)
  eslint-plugin-import → import tartibi, mavjud bo'lmagan import, davriy import

Plaginlar — ESLint qoidalar to'plamini kengaytiradi (har texnologiyaning o'z qoidalari): @typescript-eslint — TypeScript qoidalari (no-explicit-any, no-floating-promises — kutilmagan await yo'qligi, tip xavfsizligi); eslint-plugin-react + eslint-plugin-react-hooks — React qoidalari (eng muhimi react-hooks/rules-of-hooks — hook faqat komponent tepasida — 11-QISM — va react-hooks/exhaustive-deps — useEffect bog'liqlik massivi to'liqmi); eslint-plugin-jsx-a11y — JSX qulaylik (imgda alt, buttonda matn — nogironlar uchun — 13-QISM); eslint-plugin-import — import bilan bog'liq (import tartibi, mavjud bo'lmagan modul importi, davriy bog'liqlik). Plagin o'rnatiladi (npm i -D eslint-plugin-react) va konfiguratsiyaga qo'shiladi. Flat config'da plagin import qilinib, plugins obyektiga va kerakli qoidalar rulesga qo'yiladi (Misol 6 — quyida). Plaginlar tanlovi loyiha stack'iga bog'liq: React loyiha → react + react-hooks + jsx-a11y; hamma joyda → import + @typescript-eslint.

2.3. Prettier (format)

text

  PRETTIER — kodni AVTOMATIK formatlaydi (izchil ko'rinish — munozarasiz):

  NIMA QILADI (faqat KO'RINISH — mantiqqa tegmaydi):
  → bo'shliq (indent), qator uzunligi, tirnoq (' yoki "), vergul, qavs
  → "fikrsiz" (opinionated) — bitta to'g'ri usul (munozarani tugatadi)

  OLDIN (har xil):           KEYIN (Prettier — izchil):
  const x={a:1,b:2}          const x = { a: 1, b: 2 };
  function f( a,b ){return a} function f(a, b) {
                               return a;
                             }

  SOZLASH (.prettierrc — kam sozlash — default yaxshi):
  { "semi": true, "singleQuote": false, "printWidth": 80, "tabWidth": 2 }

  ISHLATISH:
  npx prettier --write .     // barcha faylni formatla
  // editor: "format on save" (saqlaganda avtomatik)

  ESLINT + PRETTIER (birga):
  → ESLint — sifat (mantiq); Prettier — format (ko'rinish)
  → eslint-config-prettier (ESLint format qoidalarini o'chir — Prettier qiladi)

  ❗ Prettier — avtomatik format (bo'shliq/qator/tirnoq — izchil, munozarasiz)
  ❗ ESLint (sifat) + Prettier (format) — alohida vazifa; eslint-config-prettier (mojaroni hal)

Prettier (format) — kodni avtomatik formatlash. Prettier — kodni avtomatik formatlaydigan vosita (faqat ko'rinish — mantiqqa tegmaydi). Nima qiladi: bo'shliq (indent — 2 yoki 4), qator uzunligi (uzun qatorni bo'lish), tirnoq (' yoki "), vergul (trailing comma), qavs joylashuvi — izchil ko'rinish. Prettier "fikrsiz" (opinionated) — bitta "to'g'ri" usul (kam sozlama — munozarani tugatadi — "tab yoki bo'shliq?", "tirnoq qaysi?" — Prettier hal qiladi — jamoa bahslashmaydi). Oldin (har dasturchi har xil — const x={a:1,b:2}, function f( a,b ){...}) → keyin (Prettier — izchil — const x = { a: 1, b: 2 };, to'g'ri bo'shliq). Sozlash (.prettierrc — kam sozlash — default yaxshi): semi (nuqta-vergul), singleQuote (tirnoq turi), printWidth (qator uzunligi — 80), tabWidth (indent — 2). Ishlatish: npx prettier --write . (barcha faylni formatla), editor "format on save" (saqlaganda avtomatik — eng qulay — yozasiz, saqlaysiz, formatlanadi). ESLint + Prettier (birga ishlatish): ESLint — sifat (mantiq), Prettier — format (ko'rinish) — alohida vazifa; lekin ESLint'da ham format qoidalari bor (eski) — mojaro bo'lmasin uchun eslint-config-prettier (ESLint'ning format qoidalarini o'chiradi — Prettier qiladi — har biri o'z ishini). Ikki nuqta: (1) Prettier — avtomatik format (bo'shliq/qator/tirnoq — izchil, munozarasiz — "fikrsiz" — bitta usul); (2) ESLint (sifat) + Prettier (format) — alohida vazifa; eslint-config-prettier (mojaroni hal — ESLint format qoidalarini o'chir). Prettier — format munozarasini tugatadi (jamoa "tab yoki bo'shliq" bahslashmaydi — Prettier hal qiladi — vaqt tejash, izchillik). "Format on save" — eng qulay (yozasiz, formatlanadi — o'ylamaysiz). Bu 15.2: 2.7 (review — format avtomatik)ning asosi (Prettier — format izchil — review'da munozara yo'q). Har zamonaviy loyihada Prettier (izchil format — qo'lda emas).

2.3.1. `.prettierignore` va editor sozlamalari

Prettier hamma faylni formatlamasligi kerak (build natijalari, avtomatik generatsiya qilingan fayllar). Buning uchun .prettierignore fayli — .gitignore bilan bir xil sintaksis:

text

  .prettierignore (formatlanmaydigan fayllar):
  node_modules
  dist
  build
  coverage
  .next
  package-lock.json      # avtomatik — qo'l tegmasin
  *.min.js               # minifikatsiya qilingan — formatlamaslik

.prettierignore — Prettier tegmasligi kerak bo'lgan yo'llar: build chiqishi (dist, build, .next), bog'liqliklar (node_modules), avtomatik fayllar (package-lock.json — qo'lda o'zgartirilmaydi), minifikatsiya qilingan fayllar (*.min.js — allaqachon siqilgan). Sintaksis .gitignore bilan bir xil. Buni qo'ymasa, Prettier keraksiz fayllarni ham qayta formatlaydi (sekin, keraksiz o'zgarishlar). Editor integratsiyasi ("format on save") — eng qulay ishlatish usuli: VS Code'da Prettier kengaytmasi (esbenp.prettier-vscode) o'rnatiladi va sozlamada saqlashda avtomatik formatlash yoqiladi:

json

// .vscode/settings.json — loyiha bilan git'ga qo'shiladi (jamoada izchil):
{
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.formatOnSave": true,
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": "explicit"   // saqlashda ESLint --fix ham ishlaydi
  },
  "eslint.useFlatConfig": true           // flat config (2.2.1) uchun
}

.vscode/settings.json — loyiha bilan birga git'ga qo'shiladi (.gitignorega kirmaydi), shunda butun jamoa bir xil sozlamada ishlaydi (yangi a'zo klonlaydi — darrov "format on save" ishlaydi). editor.formatOnSave — saqlaganda Prettier formatlaydi; editor.codeActionsOnSave bilan source.fixAll.eslint — saqlaganda ESLint tuzatiladiganlarni ham tuzatadi. Bu tavsiya qilingan kengaytmalarni ham (.vscode/extensions.json) qo'shsangiz, yangi a'zoga VS Code ularni o'rnatishni taklif qiladi.

2.4. Husky (git hooks)

text

  HUSKY — GIT HOOKS (git hodisalarda avtomatik skript — commit'dan oldin tekshir):

  GIT HOOKS — git hodisalarida ishlaydigan skriptlar:
  → pre-commit — COMMIT'dan oldin (lint/format tekshir — buzuq kod ketmasin)
  → commit-msg — commit xabari tekshir (conventional commits — 4.5)
  → pre-push — PUSH'dan oldin (test — buzuq kod push bo'lmasin)

  HUSKY — git hooks'ni OSON sozlash (qo'lda .git/hooks murakkab):
  npm install -D husky
  npx husky init                    // husky o'rnatish

  .husky/pre-commit (fayl):
  npx lint-staged                   // o'zgargan fayllarni tekshir 2.5-bob

  NATIJA:
  $ git commit -m "yangi xususiyat"
    → pre-commit ishlaydi: ESLint + Prettier (o'zgargan fayllar)
    ✗ xato bo'lsa — commit TO'XTAYDI (tuzat, keyin commit)
    ✓ toza bo'lsa — commit o'tadi

  ❗ Husky — git hooks (commit/push'dan oldin avtomatik tekshir — buzuq kod ketmaydi)
  ❗ pre-commit (lint/format) — eng keng (har commit toza kod kafolati)

Husky (git hooks) — git hodisalarida avtomatik tekshiruv. Git hooks — git hodisalarida (commit, push) avtomatik ishlaydigan skriptlar: (1) pre-commit — commit'dan oldin (eng keng — lint/format tekshir — buzuq/iflos kod git'ga ketmasin); (2) commit-msg — commit xabarini tekshir (conventional commits — feat:, fix: — 4.5); (3) pre-push — push'dan oldin (test — buzuq kod push bo'lmasin). Husky — git hooks'ni oson sozlaydigan vosita (qo'lda .git/hooks murakkab, git'ga commit qilinmaydi — Husky boshqaradi): npm install -D husky, npx husky init (o'rnatish — .husky/ papka yaratadi). .husky/pre-commit faylda: npx lint-staged (o'zgargan fayllarni tekshir — 2.5). Natija: git commit qilinganda — pre-commit avtomatik ishlaydi (ESLint + Prettier o'zgargan fayllarga): agar xato bo'lsa (lint xatosi, format xato) — commit to'xtaydi (dasturchi tuzatsin, keyin commit); agar toza — commit o'tadi. Ikki nuqta: (1) Husky — git hooks (commit/push'dan oldin avtomatik tekshir — buzuq kod ketmaydi — kafolat); (2) pre-commit (lint/format) — eng keng (har commit toza kod kafolati — dasturchi unutsa ham hook tekshiradi). Husky — kod sifatini kafolatlaydi (CI'dan ham erta — local'da, commit paytida — git'ga umuman iflos kod ketmaydi). Bu 14.9: Misol 3 (pre-commit secret scan)ning umumiy versiyasi (pre-commit — lint, format, secret, test — har xil tekshiruv). Nega Husky (qo'lda git hooks o'rniga): qo'lda .git/hooks git'ga commit qilinmaydi (har dasturchi o'zi o'rnatishi kerak — unutiladi); Husky package.jsonda (git'da — har dasturchi npm installda avtomatik o'rnatadi — izchil). Pre-commit hook — "darvoza" (iflos kod o'tmaydi). Husky — git workflow'ni kod sifati bilan bog'laydi (commit = toza kod). Defense in depth — pre-commit (local) + CI (PR — 2.6) — ikki qatlam.

2.5. lint-staged (faqat o'zgargan)

text

  lint-staged — faqat O'ZGARGAN (staged) fayllarni tekshir/formatla (TEZ):

  MUAMMO: har commit'da BUTUN loyihani lint/format — SEKIN (minglab fayl)
  YECHIM: faqat COMMIT qilinayotgan (staged) fayllar — tez (5-10 fayl)

  SOZLASH (package.json yoki .lintstagedrc):
  "lint-staged": {
    "*.{ts,tsx,js,jsx}": [
      "eslint --fix",        // o'zgargan JS/TS — lint + tuzat
      "prettier --write"     // format
    ],
    "*.{css,md,json}": "prettier --write"   // boshqa fayllar — faqat format
  }

  OQIM (pre-commit'da — 2.4):
  git commit → Husky pre-commit → lint-staged →
    faqat staged fayllar: eslint --fix + prettier --write →
    tuzatilgan fayllarni qayta stage → commit

  ❗ lint-staged — faqat o'zgargan (staged) fayllar (tez — butun loyiha emas)
  ❗ Husky (pre-commit) + lint-staged (o'zgargan) — birga: tez, avtomatik tekshir

lint-staged (faqat o'zgargan) — faqat o'zgargan fayllarni tekshirish. Muammo: har commit'da butun loyihani lint/format qilish sekin (minglab fayl — har commit 30 soniya — noqulay). Yechim — lint-staged: faqat commit qilinayotgan (staged — git add qilingan) fayllarni tekshir (odatda 5-10 fayl — tez — 2-3 soniya). Sozlash (package.json yoki .lintstagedrc): "lint-staged": { "*.{ts,tsx,js,jsx}": ["eslint --fix", "prettier --write"], "*.{css,md,json}": "prettier --write" } — JS/TS fayllarga ESLint (lint + tuzat) + Prettier (format), boshqa fayllarga (CSS, markdown) faqat Prettier (format). Oqim (pre-commit'da — 2.4): git commit → Husky pre-commit → lint-staged → faqat staged fayllarga eslint --fix + prettier --write → tuzatilgan fayllarni qayta stage → commit (toza kod bilan). Ikki nuqta: (1) lint-staged — faqat o'zgargan (staged) fayllar (tez — butun loyihani emas — commit tez); (2) Husky (pre-commit) + lint-staged (o'zgargan) — birga: tez, avtomatik tekshir (Husky — qachon — pre-commit; lint-staged — nimani — faqat o'zgargan). Bu kombinatsiya (Husky + lint-staged) — standart (har commit'da avtomatik, lekin tez — faqat o'zgargan fayllar). Nega faqat o'zgargan: (1) tez (5 fayl vs minglab — commit tez, noqulaylik yo'q); (2) mantiqli (faqat siz o'zgartirgan fayllar — eski fayllar (siz tegmagan) lint xatosi commit'ingizni bloklamasin — adolatli). --fix/--write — avtomatik tuzatadi (format, ba'zi lint — siz qo'lda tuzatmaysiz — vosita qiladi, qayta stage). Bu — kod sifatini silliq avtomatlashtirish (har commit toza, lekin tez — sezilmas). Husky + lint-staged — zamonaviy loyiha standarti (commit = toza, tez). Bu to'rt vosita (ESLint + Prettier + Husky + lint-staged) — birga kod sifatini to'liq avtomatlashtiradi.

2.5.1. commitlint — commit xabar standarti (commit-msg hook)

Kod sifati bilan bir qatorda commit xabar sifati ham muhim (o'qiladigan tarix, avtomatik changelog, semantik versiya). Conventional Commits — standart format: tur(qamrov): tavsif, masalan feat(auth): login qo'shildi, fix: null xatoni tuzatish. commitlint bu formatni commit-msg hook'da tekshiradi:

text

  CONVENTIONAL COMMITS FORMATI:
  <tur>[(qamrov)][!]: <tavsif>
  → tur: feat | fix | docs | refactor | test | chore | ci | perf ...
  → feat = yangi xususiyat, fix = xato tuzatish (SemVer: feat=minor, fix=patch)
  → "!" yoki "BREAKING CHANGE:" = major (buzuvchi o'zgarish)

  ✅ feat(cart): savatga mahsulot qo'shish
  ✅ fix: sahifa yuklanmayotgan xatoni tuzatish
  ❌ "narsalarni tuzatdim"        → commitlint rad etadi (tur yo'q)
  ❌ "WIP"                        → rad etadi

bash

# O'rnatish va commit-msg hook (Husky bilan):
npm install -D @commitlint/cli @commitlint/config-conventional
echo "export default { extends: ['@commitlint/config-conventional'] };" > commitlint.config.js
# .husky/commit-msg (fayl ichi):
npx --no -- commitlint --edit "$1"

commitlint — commit xabarini commit-msg git hook'da tekshiradi (Husky orqali). @commitlint/config-conventional — Conventional Commits qoidalarini beradi. Xabar formatga mos bo'lmasa (feat:, fix: prefiksi yo'q, yoki bo'sh) — commit to'xtaydi. Nega bu foydali: (1) tarix o'qiladigan (git log — nima o'zgarganini ko'rasiz); (2) avtomatik changelog (feat/fixdan generatsiya); (3) semantik versiya (feat → minor, fix → patch, BREAKING CHANGE → major — avtomatik). commit-msg — Husky boshqaradigan uchinchi keng hook (pre-commit lint, pre-push test bilan bir qatorda).

2.5.2. TypeScript type-check (`tsc --noEmit`)

ESLint tip xatolarini to'liq tutmaydi (u statik naqsh tahlili qiladi, tip tizimini emas). Haqiqiy tip tekshiruvi — TypeScript kompilyatorining o'zi:

text

  tsc --noEmit → kodni KOMPILYATSIYA qiladi (tip tekshiradi), lekin
                 .js FAYL CHIQARMAYDI (--noEmit) — faqat tip xatolarini topadi

  package.json:
  "scripts": { "type-check": "tsc --noEmit" }

  → xato: "Type 'string' is not assignable to type 'number'" — CI'ni yiqitadi

tsc --noEmit — TypeScript kompilyatori kodni tekshiradi (tip xatolari, mavjud bo'lmagan xususiyat, noto'g'ri argument), lekin .js fayl chiqarmaydi (--noEmit — faqat tekshirish maqsadi). Nega ESLint yetarli emas: ESLint har fayldagi naqshni ko'radi, lekin butun loyiha bo'ylab tip oqimini (bir fayldagi funksiya boshqa faylda noto'g'ri chaqirilishi) tutmaydi — buni faqat kompilyator biladi. Shuning uchun type-check alohida qadam (CI'da — 2.6). Odatda pre-commit'da tsc ishlatilmaydi (sekin — butun loyihani kompilyatsiya qiladi, lint-staged bilan bir fayl tekshirib bo'lmaydi), lekin CI'da va pre-push'da albatta bo'lishi kerak. Uchta mustaqil tekshiruv birga: ESLint (naqsh/sifat) + Prettier (format) + tsc (tip) — hech biri qolganini almashtirmaydi.

2.6. CI'da va to'liq sozlash

text

  CI'DA — PR'da yana tekshir (local hook o'tkazilsa ham — qatlam):

  # .github/workflows/ci.yml 10.9-bob:
  - run: npm run lint           # ESLint (xato bo'lsa CI qizil)
  - run: npx prettier --check . # format tekshir (formatlanmaganni topadi)
  - run: npm run type-check     # TypeScript (tsc --noEmit)
  - run: npm test               # test

  NEGA CI HAM (Husky bor-ku):
  → Husky local (dasturchi --no-verify bilan o'tkazib yuborishi mumkin)
  → CI — markaziy, majburiy (PR yashil bo'lmasa merge yo'q — 15.2)

  TO'LIQ SOZLASH OQIMI:
  1. ESLint + Prettier o'rnat + sozla (eslint.config.js, .prettierrc)
  2. eslint-config-prettier (mojaro hal — 2.3)
  3. Husky + lint-staged (pre-commit — 2.4, 2.5)
  4. CI (PR'da lint/format/test — qatlam)
  5. Editor (VS Code — format on save, ESLint plugin)

  ❗ CI'da ham lint/format (local hook --no-verify bilan o'tkazilsa — markaziy qatlam)
  ❗ To'liq oqim — ESLint+Prettier (sozla) → Husky+lint-staged (commit) → CI (PR) → editor

CI'da va to'liq sozlash — to'liq avtomatlashtirish oqimi. CI'da (PR'da — 10.9) yana tekshirish: npm run lint (ESLint — xato bo'lsa CI qizil), prettier --check . (format tekshir — --check formatlanmaganni topadi — --write emas — CI faqat tekshiradi, tuzatmaydi), type-check (TypeScript), test. Nega CI ham (Husky bor-ku — pre-commit): Husky local (dasturchi mashinasida — git commit --no-verify bilan o'tkazib yuborishi mumkin — hook ishlamaydi); CI — markaziy, majburiy (PR yashil bo'lmasa merge yo'q — 15.2: 2.6 — server'da — chetlab o'tib bo'lmaydi). Demak: Husky — local, tez, qulay (commit paytida); CI — markaziy, majburiy (kafolat — local chetlab o'tilsa). Defense in depth (editor → pre-commit → CI). To'liq sozlash oqimi: (1) ESLint + Prettier o'rnat + sozla (eslint.config.js, .prettierrc); (2) eslint-config-prettier (mojaro hal — 2.3); (3) Husky + lint-staged (pre-commit — 2.4, 2.5); (4) CI (PR'da lint/format/test — qatlam); (5) editor (VS Code — "format on save", ESLint plugin — real vaqt). Ikki nuqta: (1) CI'da ham lint/format (local hook --no-verify bilan o'tkazilsa — markaziy qatlam — majburiy); (2) to'liq oqim — ESLint+Prettier (sozla) → Husky+lint-staged (commit) → CI (PR) → editor (real vaqt). Bu to'liq oqim — kod sifatini har bosqichda (yozish — editor; commit — Husky; PR — CI) avtomatik tekshiradi (shift left — 14.9: 2.3 — erta, ko'p qatlam). Har qatlam o'z roli: editor (darrov — yozish paytida), pre-commit (commit — local kafolat), CI (PR — markaziy kafolat). Bu — professional loyihaning kod sifati infratuzilmasi (qo'lda emas — avtomatik, izchil, ko'p qatlamli). Bir marta sozlansa (boshida) — keyin avtomatik (har dasturchi, har commit, har PR — izchil sifat). Bu — 15.1 (toza kod) + 15.2 (review)ni avtomatlashtirish (vositalar — qo'lda mehnatni kamaytiradi).

2.7. Best practices va keng muammolar

text

  BEST PRACTICES va KENG MUAMMOLAR:

  BEST PRACTICES:
  ✓ Prettier — format (ESLint format qoidalarini o'chir — eslint-config-prettier)
  ✓ ESLint — sifat/xato (recommended + loyiha qoidalari)
  ✓ Husky + lint-staged (commit — tez, avtomatik)
  ✓ CI (markaziy — majburiy qatlam)
  ✓ Editor (format on save — eng qulay)
  ✓ Jamoa kelishuvi (qoidalar — birga; har kim emas)

  KENG MUAMMOLAR:
  ✗ ESLint vs Prettier mojaro (ikkalasi format) → eslint-config-prettier
  ✗ Juda ko'p qoida (har narsani error — demotivatsiya) → muhimlarini
  ✗ Qoidalar kelishilmagan (har kim boshqacha) → jamoa standarti
  ✗ Hook sekin (butun loyiha) → lint-staged (faqat o'zgargan)
  ✗ Qoidalarni o'chirib tashlash (eslint-disable hamma joyda) → sababli faqat

  ❗ Best — Prettier (format) + ESLint (sifat) + Husky/lint-staged (commit) + CI + editor
  ❗ Muammolar — mojaro (eslint-config-prettier), ko'p qoida, sekin (lint-staged)

Best practices va keng muammolar — vositalarni to'g'ri ishlatish. Best practices: (1) Prettier — format (ESLint'ning format qoidalarini o'chir — eslint-config-prettier — mojaroni oldini oladi — 2.3); (2) ESLint — sifat/xato (recommended + loyiha maxsus qoidalari — 2.2); (3) Husky + lint-staged (commit — tez, avtomatik — 2.4, 2.5); (4) CI (markaziy — majburiy qatlam — 2.6); (5) editor (format on save — eng qulay — yozasiz, formatlanadi); (6) jamoa kelishuvi (qoidalar — jamoa birga kelishadi — har kim o'zicha emas — izchillik). Keng muammolar: (1) ESLint vs Prettier mojaro (ikkalasi format qoidalariga ega — bir-biriga zid — masalan ESLint "bo'shliq", Prettier "boshqacha" — kurashadi) → eslint-config-prettier (ESLint format qoidalarni o'chir — Prettier qiladi); (2) juda ko'p qoida (har narsani error — har kichik narsaga qizil — demotivatsiya, ish sekinlashadi) → faqat muhimlarini error, qolganini warn yoki off; (3) qoidalar kelishilmagan (har dasturchi boshqacha sozlama — chalkash) → jamoa standarti (bir konfiguratsiya — hamma uchun); (4) hook sekin (butun loyihani tekshir — commit sekin) → lint-staged (faqat o'zgargan — 2.5); (5) qoidalarni o'chirib tashlash (eslint-disable hamma joyda — qoidalarni chetlab o'tish — vosita foydasiz) → sababli faqat (eslint-disable faqat haqiqiy sabab bilan — kommentariya bilan — har joyda emas). Ikki nuqta: (1) best — Prettier (format) + ESLint (sifat) + Husky/lint-staged (commit) + CI + editor (to'liq oqim — 2.6); (2) muammolar — mojaro (eslint-config-prettier), ko'p qoida (muhimlarini), sekin (lint-staged), o'chirib tashlash (sababli faqat). Bu vositalar — yordamchi (dushman emas) — to'g'ri sozlansa (kelishilgan qoida, mojarosiz, tez) — kod sifatini silliq avtomatlashtiradi; noto'g'ri (ko'p qoida, mojaro, sekin) — to'siq (demotivatsiya, ish sekin). Balans (15.1: 2.8 kabi) — yetarli qoida (muhimlari — error), tez (lint-staged), izchil (jamoa standarti). Zamonaviy loyihada bu sozlash bir marta (boshida — yoki create-next-app keladi) — keyin avtomatik foyda. Bu — professional kod sifati infratuzilmasini sozlash ko'nikmasi.

2.8. Performans (kesh), jamoa uchun umumiy konfiguratsiya va monorepo

Bir marta sozlagach, uch amaliy masala qoladi: linter tez ishlashi, jamoa/loyihalar bo'ylab bir xil qoida, va ko'p paketli (monorepo) loyihada boshqarish.

text

  PERFORMANS (kesh):
  eslint . --cache          → o'zgarmagan fayllar qayta tekshirilmaydi (.eslintcache)
  → CI'da ham keshni saqlash (actions/cache) — takroriy ishlash tez

  UMUMIY KONFIGURATSIYA (shared config paket):
  @kompaniya/eslint-config  → bir paket, hamma loyiha shuni import qiladi
  eslint.config.js:  import base from "@kompaniya/eslint-config";
                     export default [...base, { /* loyiha maxsus */ }];
  → izchillik: qoida bir joyda yangilanadi → hamma loyiha oladi

  MONOREPO (15.4 cross-ref):
  → ildizda umumiy eslint.config.js + prettier config (barcha paket meros oladi)
  → Turborepo: "lint" taskni keshlash (o'zgarmagan paket qayta lint qilinmaydi)

Performans (kesh) — katta loyihada eslint . sekin bo'lishi mumkin. --cache bayrog'i natijani .eslintcache fayliga saqlaydi va keyingi safar faqat o'zgargan fayllarni tekshiradi (o'zgarmaganlar o'tkazib yuboriladi). Buni .gitignorega qo'ying. CI'da keshni saqlab qolish (masalan actions/cache bilan .eslintcache) takroriy ishlashni tezlashtiradi. Prettier'da ham --cache bor. Kesh — lint-staged'dan (faqat staged fayl) mustaqil to'ldiruvchi optimizatsiya (butun loyihani lint qilganda foydali).

Umumiy konfiguratsiya (shared config) — ko'p loyiha yoki katta jamoada har birida qoidalarni takrorlash — ziddiyat va ko'chirish xatosi manbai. Yechim — qoidalarni alohida npm paketga chiqarish (@kompaniya/eslint-config, @kompaniya/prettier-config) va har loyihada import qilish: import base from "@kompaniya/eslint-config"; export default [...base, { /* loyiha maxsus qo'shimchalar */ }];. Bir joyda yangilaysiz — barcha loyiha yangilanadi (izchillik, markazlashgan boshqaruv). Ochiq misollar: eslint-config-airbnb, eslint-config-next (Next.js bilan keladi) — bular ham aslida umumiy config paketlar. Prettier uchun package.jsonda "prettier": "@kompaniya/prettier-config" bilan ulanadi.

Monorepo (bir repozitoriyda ko'p paket — 15.4-bob) — kod sifati bir necha paketga tarqaladi. Amaliyot: ildizda (root) umumiy eslint.config.js va Prettier konfiguratsiyasi qo'yiladi, paketlar shuni meros oladi (yoki ildizdan --config bilan ishlatiladi) — bitta manba, izchil qoida. Husky ildizda bir marta o'rnatiladi (butun monorepo uchun bitta .husky/). Turborepo/Nx (15.4) lint/type-check tasklarni keshlaydi — o'zgarmagan paket qayta lint qilinmaydi (katta monorepoda katta tezlik). Monoreponing batafsili — 15.4-bob.

2.9. Qachon qaysi qoida to'plami (Airbnb / Standard / o'z)

Loyiha boshida keng savol: qanday qoida to'plamidan boshlash? Uch keng yondashuv bor:

text

  QOIDA TO'PLAMLARI — qat'iylik va nazorat bo'yicha:

  ┌─────────────────┬──────────────────────────────────────────────┐
  │ eslint:recommended│ Minimal — faqat aniq buglar. Xavfsiz boshlanish│
  │ + typescript-eslint│ (kam bahs). Ko'pchilik loyiha uchun yetarli.  │
  ├─────────────────┼──────────────────────────────────────────────┤
  │ Airbnb          │ Juda qat'iy, batafsil uslub. Izchil, lekin     │
  │                 │ ko'p qoida (o'rganish/moslash kerak).          │
  ├─────────────────┼──────────────────────────────────────────────┤
  │ Standard        │ Konfiguratsiyasiz, o'z fikri (masalan ; yo'q). │
  │                 │ Tez, lekin moslash cheklangan.                 │
  ├─────────────────┼──────────────────────────────────────────────┤
  │ O'z to'plamingiz │ recommended + jamoa kelishgan qo'shimchalar.   │
  │                 │ Eng moslashuvchan (aksar jamoa shu yo'lni tanlaydi)│
  └─────────────────┴──────────────────────────────────────────────┘

Qaysi qoida to'plami? (1) eslint:recommended + typescript-eslint — minimal, faqat aniq xatolar (kam bahs, xavfsiz boshlanish). Ko'pchilik loyiha uchun yetarli — bu asosdan boshlash tavsiya etiladi. (2) Airbnb (eslint-config-airbnb) — juda qat'iy, batafsil uslub qoidalari (izchillik yuqori, lekin ko'p qoida — moslashish va o'rganish vaqt talab qiladi; ba'zi qoidalar bahsli). (3) Standard (eslint-config-standard) — o'z qat'iy fikri bor (masalan nuqta-vergulsiz), sozlash deyarli yo'q (tez, lekin moslash cheklangan — Prettier bilan qo'shish murakkab). (4) O'z to'plamingiz — recommendeddan boshlab, jamoa kelishgan qoidalarni qo'shish (eng moslashuvchan — aksar jamoa shu yo'lni tanlaydi). Umumiy tavsiya: recommended + typescript-eslintdan boshlang, format Prettier'ga bering, keyin loyiha ehtiyojiga qarab qoida qo'shing (Airbnb'ni to'liq olishdan ko'ra tanlab olgan qulay). Muhimi — jamoa kelishishi (qaysi to'plam bo'lsa ham — izchillik qoidaning o'zidan muhimroq).

3. Sintaksis — sozlash ma'lumotnoma

text

ESLINT 2.2-bob:       eslint.config.js — js.recommended + tseslint + rules; eslint . --fix
FLAT vs ESKI (2.2.1): eslint.config.js (yangi, ESLint 9) vs .eslintrc.* (eski, env/extends)
PLAGINLAR (2.2.2):  @typescript-eslint, react, react-hooks, jsx-a11y, import
PRETTIER 2.3-bob:     .prettierrc — { semi, singleQuote, printWidth }; prettier --write .
IGNORE (2.3.1):     .prettierignore — dist, node_modules, *.min.js
EDITOR (2.3.1):     .vscode/settings.json — formatOnSave + codeActionsOnSave (ESLint)
MOJARO 2.3-bob:       eslint-config-prettier (ESLint format qoidalarini o'chir)
HUSKY 2.4-bob:        npx husky init; .husky/pre-commit → npx lint-staged
LINT-STAGED 2.5-bob:  "lint-staged": { "*.{ts,tsx}": ["eslint --fix", "prettier --write"] }
COMMITLINT (2.5.1): @commitlint/config-conventional; .husky/commit-msg → commitlint --edit
TYPE-CHECK (2.5.2): tsc --noEmit (tip tekshiruv — .js chiqarmaydi)
CI 2.6-bob:           npm run lint + prettier --check + type-check + test
PERFORMANS 2.8-bob:   eslint . --cache (.eslintcache); shared config paket; monorepo 15.4-bob
QOIDA TO'PLAMI 2.9-bob: recommended (minimal) | Airbnb (qat'iy) | Standard | o'z

4. Batafsil misollar

Har misol: Maqsad + sozlash/kod + "Bu nima qiladi".

Misol 1 — ESLint sozlash (2.2)

Maqsad: TypeScript loyihaga ESLint sozlash — sifat qoidalari bilan. Bu kod xatolarini yozish paytida topadi.

tsx

// eslint.config.js (flat config — yangi format):
import js from "@eslint/js";
import tseslint from "typescript-eslint";

export default [
  js.configs.recommended,              // JS standart qoidalar
  ...tseslint.configs.recommended,     // TypeScript qoidalari (7-QISM)
  {
    files: ["**/*.{ts,tsx}"],
    rules: {
      // Xatolar (error — CI yiqitadi):
      "no-unused-vars": "off",                          // TS versiyasini ishlat:
      "@typescript-eslint/no-unused-vars": "error",     // ishlatilmagan o'zgaruvchi
      "eqeqeq": ["error", "always"],                    // === majburiy (== taqiq)
      "no-var": "error",                                // var taqiq (let/const)

      // Ogohlantirishlar (warn — sariq, lekin o'tadi):
      "no-console": "warn",                             // console.log — ogohlantirish
      "@typescript-eslint/no-explicit-any": "warn",     // any — ogohlantirish (7-QISM)
    },
  },
  { ignores: ["dist/", "node_modules/", ".next/"] },    // tekshirilmaydiganlar
];

Bu nima qiladi: Bu — ESLint sozlash (TypeScript loyihaga — 2.2). eslint.config.js (flat config — ESLint'ning yangi sozlash formati): (1) js.configs.recommended — JavaScript standart qoidalari (eng keng muammolar — masalan duplicate keys, unreachable code); (2) tseslint.configs.recommended — TypeScript qoidalari (7-QISM — tip bilan bog'liq); (3) maxsus rules — loyiha qoidalari. Xatolar (error — CI'ni yiqitadi — tuzatish majburiy): @typescript-eslint/no-unused-vars (ishlatilmagan o'zgaruvchi — TS versiyasi — no-unused-vars o'chiq, TS versiyasi yoqilgan — to'g'riroq), eqeqeq (=== majburiy — == tip xavfi — 2-QISM), no-var (var taqiq — let/const). Ogohlantirishlar (warn — sariq, lekin o'tadi — yaxshilash, lekin bloklamaydi): no-console (console.log — production'da qolmasin — ogohlantirish), @typescript-eslint/no-explicit-any (any — 7-QISM — tip yo'qotadi — ogohlantirish). ignores — tekshirilmaydigan papkalar (dist, node_modules, .next — build natijalari — tekshirish keraksiz). Qoida darajalari: "error" (qizil — CI yiqiladi — jiddiy), "warn" (sariq — o'tadi — yaxshilash), "off" (o'chiq). Bu sozlama — kod sifatini yozish paytida (editor'da qizil/sariq) va CI'da (PR — error bloklaydi) tekshiradi. Nega bu muhim: ESLint xato/yomon naqshni yozish paytida topadi (production'dan oldin — == ishlatsangiz darrov qizil — tuzatasiz). recommended (yaxshi boshlanish) + maxsus qoidalar (loyihaga moslash — masalan console.log taqiq). Balans 2.7-bob — muhimlarni error (===, unused), yaxshilashlarni warn (console, any) — juda ko'p error demotivatsiya. Bu — har TS loyihaning ESLint asosi (sifat qoidalari — avtomatik tekshirish).

Misol 2 — Prettier + ESLint birga (2.3)

Maqsad: Prettier va ESLint'ni mojarosiz birga ishlatish — har biri o'z vazifasini. Bu format va sifatni alohida boshqaradi.

json

// .prettierrc (format sozlamasi — kam, default yaxshi):
{
  "semi": true,
  "singleQuote": false,
  "printWidth": 100,
  "tabWidth": 2,
  "trailingComma": "es5"
}

tsx

// eslint.config.js — Prettier bilan mojaroni hal:
import js from "@eslint/js";
import tseslint from "typescript-eslint";
import prettier from "eslint-config-prettier";   // ❗ ESLint format qoidalarini o'chiradi

export default [
  js.configs.recommended,
  ...tseslint.configs.recommended,
  { rules: { /* sifat qoidalari — Misol 1 */ } },
  prettier,   // ❗ OXIRIDA — ESLint'ning format qoidalarini bekor qiladi (Prettier qiladi)
];

json

// package.json scripts:
{
  "scripts": {
    "lint": "eslint .",
    "format": "prettier --write .",
    "format:check": "prettier --check ."
  }
}

Bu nima qiladi: Bu — Prettier va ESLint'ni mojarosiz birga ishlatish 2.3-bob. Muammo: ESLint'da ham format qoidalari bor (eski — masalan indent, quotes), Prettier ham format qiladi — agar ikkalasi yoqilgan bo'lsa, ular kurashadi (ESLint "bo'shliq 4" deydi, Prettier "2 qiladi" — har save'da o'zgaradi — chalkash). Yechim: (1) .prettierrc — format sozlamasi (semi — nuqta-vergul, singleQuote: false — qo'sh tirnoq, printWidth: 100 — qator uzunligi, tabWidth: 2 — indent, trailingComma — vergul) — kam sozlama (Prettier default yaxshi — faqat ba'zi afzalliklar); (2) eslint-config-prettier — ESLint sozlamasiga oxirida qo'shiladi — bu ESLint'ning format qoidalarini (indent, quotes, semi — Prettier qiladigan) o'chiradi — endi ESLint faqat sifat (mantiq — unused, ===), Prettier faqat format (ko'rinish) — har biri o'z vazifasi, mojaro yo'q. (3) package.json scripts — qulay buyruqlar: lint (ESLint — sifat), format (Prettier — formatla), format:check (Prettier — tekshir, tuzatmay — CI uchun — 2.6). Natija: ESLint kod sifatini (xato, yomon naqsh), Prettier formatini (ko'rinish) — alohida, mojarosiz. Nega bu kerak: ko'p loyiha ESLint + Prettier ishlatadi, lekin mojaro (format kurashadi) — eslint-config-prettier buni hal qiladi (ESLint format qoidalari o'chiq — Prettier qiladi). Bu standart sozlama (har ESLint + Prettier loyihada — eslint-config-prettier oxirida). Tartib muhim — prettier (eslint-config-prettier) oxirida (oldingi qoidalarni bekor qiladi — keyingi sozlama oldingisini o'chiradi). Endi: yozasiz → ESLint sifatni tekshiradi (qizil xato) + Prettier formatlaydi (save'da) — birga, mojarosiz. Bu — ESLint + Prettier'ning to'g'ri kombinatsiyasi (har biri o'z ishi — sifat va format).

Misol 3 — Husky + lint-staged (2.4, 2.5)

Maqsad: Commit'dan oldin avtomatik lint/format — Husky + lint-staged bilan. Bu iflos kodning git'ga ketishini oldini oladi.

bash

# O'rnatish:
npm install -D husky lint-staged
npx husky init                    # Husky o'rnatish (.husky/ yaratadi)

json

// package.json — lint-staged sozlamasi:
{
  "lint-staged": {
    "*.{ts,tsx,js,jsx}": [
      "eslint --fix",             // o'zgargan JS/TS — lint + avtomatik tuzat
      "prettier --write"          // format
    ],
    "*.{json,css,md}": [
      "prettier --write"          // boshqa fayllar — faqat format
    ]
  }
}

bash

# .husky/pre-commit (fayl ichi):
npx lint-staged

text

NATIJA — git commit qilganda:
$ git add login.tsx
$ git commit -m "login qo'shildi"
  → Husky pre-commit ishlaydi
  → lint-staged: faqat login.tsx (staged) tekshiriladi
    ✓ eslint --fix (xato tuzatiladi)
    ✓ prettier --write (formatlanadi)
  → agar tuzatilmaydigan xato (masalan === kerak) → COMMIT TO'XTAYDI
  → toza bo'lsa → commit o'tadi (toza kod git'da)

Bu nima qiladi: Bu — Husky + lint-staged (commit'dan oldin avtomatik tekshiruv — 2.4, 2.5). O'rnatish: npm install -D husky lint-staged, npx husky init (Husky o'rnatadi — .husky/ papka). lint-staged sozlamasi (package.json): qaysi fayllarga nima qilish — *.{ts,tsx,js,jsx} (JS/TS) → eslint --fix (lint + avtomatik tuzat) + prettier --write (format); *.{json,css,md} (boshqa) → faqat prettier --write (format — ESLint JS/TS uchun). .husky/pre-commit → npx lint-staged (commit'dan oldin lint-staged ishlaydi). Natija: git commit qilinganda — Husky pre-commit ishlaydi → lint-staged faqat staged (commit qilinayotgan — login.tsx) fayllarni tekshiradi (butun loyiha emas — tez — 2.5): eslint --fix (xato tuzatiladi — masalan ===ga o'zgartiradi) + prettier --write (formatlanadi); agar tuzatilmaydigan xato bo'lsa (masalan ishlatilmagan o'zgaruvchi — qo'lda tuzatish kerak) → commit to'xtaydi (dasturchi tuzatsin); toza bo'lsa → commit o'tadi (toza, formatlangan kod git'da). Nega bu muhim: (1) kafolat — har commit toza, formatlangan (dasturchi format/lint haqida o'ylamaydi — avtomatik); (2) tez — faqat o'zgargan fayllar (lint-staged — butun loyihani emas — commit sezilmas); (3) avtomatik tuzatish — --fix/--write ko'p narsani o'zi tuzatadi (format, ba'zi lint — dasturchi qo'lda qilmaydi). Demak: iflos kod git'ga umuman ketmaydi (commit paytida to'siladi yoki tuzatiladi). Bu CI'dan ham erta (local — commit paytida — 2.6). Husky (qachon — pre-commit) + lint-staged (nimani — o'zgargan) — birga ideal (avtomatik, tez, commit paytida). Bu standart sozlama (har professional JS/TS loyihada — Husky + lint-staged). Bir marta sozlansa — keyin har commit avtomatik (toza kod kafolati). Bu 14.9: Misol 3 (pre-commit secret)ning sifat versiyasi (pre-commit — lint/format).

Misol 4 — To'liq CI sozlash (2.6)

Maqsad: PR'da kod sifatini markaziy tekshirish — CI bilan. Bu local hook chetlab o'tilsa ham kafolat.

yaml

# .github/workflows/ci.yml — kod sifati CI 10.9-bob:
name: CI
on: [push, pull_request]

jobs:
  quality:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20, cache: "npm" }
      - run: npm ci

      # Kod sifati (har biri xato bo'lsa CI qizil — merge yo'q):
      - run: npm run lint            # ESLint (sifat — Misol 1)
      - run: npx prettier --check .  # format tekshir (--check — tuzatmaydi, topadi)
      - run: npm run type-check      # TypeScript (tsc --noEmit)
      - run: npm test                # test (11.17)
      - run: npm run build           # build muvaffaqiyatlimi

text

NEGA CI HAM (Husky bor-ku — 2.6):
→ Husky LOCAL (git commit --no-verify bilan o'tkazib yuborilishi mumkin)
→ CI MARKAZIY (server'da — chetlab o'tib bo'lmaydi — majburiy qatlam)

QATLAMLAR (defense in depth):
Editor (yozishda) → Husky (commit) → CI (PR — majburiy)
→ har qatlam — kod sifati (biri o'tkazilsa, keyingi ushlaydi)

Bu nima qiladi: Bu — to'liq CI kod sifati sozlash 2.6-bob. .github/workflows/ci.yml (GitHub Actions — 10.9), har push/PR'da: npm ci (paketlar), keyin kod sifati tekshiruvlari — npm run lint (ESLint — sifat — Misol 1), prettier --check . (format tekshir — --check faqat topadi formatlanmaganni, --write emas — CI tuzatmaydi, faqat tekshiradi — agar formatlanmagan fayl bor — CI qizil), type-check (TypeScript — tip xatolari), test 11.17-bob, build (kompilyatsiya). Har biri xato bo'lsa — CI qizil (merge yo'q — 15.2: 2.6). Nega CI ham (Husky pre-commit bor-ku): Husky local (dasturchi mashinasida) — git commit --no-verify bilan hook'ni o'tkazib yuborishi mumkin (yoki Husky o'rnatilmagan), shuning uchun markaziy kafolat kerak — CI (server'da — chetlab o'tib bo'lmaydi — PR yashil bo'lmasa merge yo'q). Qatlamlar (defense in depth — 14.1: 2.3): editor (yozishda — real vaqt — darrov) → Husky (commit — local — tez) → CI (PR — markaziy — majburiy) — har qatlam kod sifatini tekshiradi (biri o'tkazilsa — keyingi ushlaydi). Nega ko'p qatlam: editor (eng erta — yozishda — qulay, lekin o'chirilishi mumkin), Husky (commit — local kafolat, lekin --no-verify), CI (PR — markaziy — chetlab o'tib bo'lmaydi — eng ishonchli). Birga — kod sifati har bosqichda (yozish, commit, PR) — izchil kafolat. --check vs --write: CI'da --check (tekshiradi — formatlanmagan bo'lsa qizil — dasturchi tuzatsin), local hook'da --write (tuzatadi — avtomatik). Bu — kod sifati infratuzilmasinin markaziy qatlami (CI — majburiy — har PR toza kod). Editor + Husky + CI — to'liq oqim (15.3 vositalari har bosqichda). Bu professional loyihaning standarti (kod sifati avtomatik, ko'p qatlamli, majburiy — qo'lda emas).

Misol 5 — eslint-disable to'g'ri ishlatish (2.7)

Maqsad: ESLint qoidasini istisno qilishni to'g'ri (sababli, cheklangan) qilish. Bu vositani chetlab o'tmasdan, zarur holatda moslashish.

tsx

// ❌ YOMON — qoidani ko'r-ko'rona o'chirish (vosita foydasiz):
/* eslint-disable */                    // BUTUN fayl uchun — hech narsa tekshirilmaydi!
function messy() { var x == 5 }

// ❌ YOMON — sababsiz, keng:
// eslint-disable-next-line
const data: any = fetchData();          // nega? — noaniq

// ✅ YAXSHI — aniq qoida + sabab (cheklangan):
// 3-tomon kutubxona tipi noto'g'ri — any zarur (issue: github.com/lib/123)
// eslint-disable-next-line @typescript-eslint/no-explicit-any
const legacyData: any = oldLibrary.getData();

// ✅ YAXSHI — qoidani LOYIHA darajasida moslash (agar tez-tez kerak bo'lsa):
// eslint.config.js: test fayllarda console OK:
{
  files: ["**/*.test.ts"],
  rules: { "no-console": "off" },       // test'da console — OK (sababli)
}

Bu nima qiladi: Bu — eslint-disable to'g'ri ishlatish (2.7 — vositani chetlab o'tmasdan moslashish). Ba'zan ESLint qoidasi zarur holatda noto'g'ri (false positive — 14.9: 2.2 — yoki haqiqiy istisno) — uni o'chirish kerak, lekin to'g'ri (sababli, cheklangan). Yomon: (1) /* eslint-disable */ (butun fayl — hech narsa tekshirilmaydi — vosita foydasiz — butun fayl himoyasiz — eng yomon); (2) // eslint-disable-next-line sababsiz (const data: any — nega any? — noaniq — keyingi dasturchi bilmaydi). Yaxshi: (1) aniq qoida + sabab (// eslint-disable-next-line @typescript-eslint/no-explicit-any — aniq qoida (faqat shu qoida, boshqalari faol) + sabab kommentariyasi ("3-tomon kutubxona tipi noto'g'ri — any zarur" + issue havolasi) — keyingi dasturchi nega ekanini biladi, va faqat bir qoida o'chiq (boshqalari himoya); (2) loyiha darajasida moslash (agar tez-tez kerak — masalan test fayllarda console.log OK — debug — eslint.config.jsda files: ["**/*.test.ts"], rules: { "no-console": "off" } — sababli, izchil — har test faylda eslint-disable yozishdan yaxshiroq). Nega bu muhim: eslint-disable — qoidani chetlab o'tish (ESLint foydasini yo'qotadi) — agar keng/sababsiz ishlatilsa (butun fayl, har joyda any) — vosita ma'nosiz (qoidalar bor, lekin chetlab o'tilgan). To'g'ri ishlatish: (1) cheklangan (aniq qoida + aniq qator — next-line — butun fayl emas); (2) sababli (kommentariya — nega — keyingi dasturchi tushunsin); (3) kam (faqat haqiqiy istisno — har noqulaylikda emas — qoidani o'zgartir yoki kodni tuzat). Agar bir qoida tez-tez o'chirilsa (har joyda eslint-disable) — bu qoida noto'g'ri sozlangan belgisi (loyiha darajasida moslash — warn/off yoki maxsus konfiguratsiya). eslint-disable — "qochish lyuki" (zarur, lekin kam, sababli) — keng ishlatilsa vosita buziladi. Bu — vositani professional ishlatish (chetlab o'tmasdan — zarur holatda, to'g'ri, sababli moslashish). Balans 2.7-bob — qoidalar foydali, lekin ba'zan istisno kerak (to'g'ri — cheklangan, sababli).

Misol 6 — React plaginlari va flat config (2.2.2)

Maqsad: React loyihaga plaginlar bilan ESLint sozlash (hook qoidalari, qulaylik, import tartibi) — flat config'da. Bu React'ga xos xatolarni topadi.

bash

# Plaginlarni o'rnatish:
npm install -D eslint-plugin-react eslint-plugin-react-hooks \
  eslint-plugin-jsx-a11y eslint-plugin-import eslint-config-prettier

tsx

// eslint.config.js — React + TS + plaginlar (flat config):
import js from "@eslint/js";
import tseslint from "typescript-eslint";
import react from "eslint-plugin-react";
import reactHooks from "eslint-plugin-react-hooks";
import jsxA11y from "eslint-plugin-jsx-a11y";
import importPlugin from "eslint-plugin-import";
import prettier from "eslint-config-prettier";

export default [
  js.configs.recommended,
  ...tseslint.configs.recommended,
  {
    files: ["**/*.{ts,tsx}"],
    plugins: {                             // plaginlar obyekt sifatida (string emas)
      react,
      "react-hooks": reactHooks,
      "jsx-a11y": jsxA11y,
      import: importPlugin,
    },
    languageOptions: {
      globals: { window: "readonly", document: "readonly" },  // eski "env" o'rniga
    },
    settings: { react: { version: "detect" } },   // React versiyasini avtomatik aniqla
    rules: {
      "react-hooks/rules-of-hooks": "error",       // hook faqat tepada (11-QISM)
      "react-hooks/exhaustive-deps": "warn",       // useEffect bog'liqlik massivi
      "jsx-a11y/alt-text": "error",                // img'da alt majburiy (13-QISM)
      "import/no-cycle": "error",                  // davriy import taqiq
      "import/order": "warn",                      // import tartibi izchil
    },
  },
  { ignores: ["dist/", "node_modules/"] },
  prettier,                                        // ❗ OXIRIDA — format qoidalarini o'chir
];

Bu nima qiladi: Bu — React loyiha uchun to'liq ESLint konfiguratsiyasi (flat config — 2.2.1 — plaginlar bilan — 2.2.2). Har plagin import qilinadi va plugins obyektiga qo'yiladi (eski formatdagi string nomlar o'rniga — flat config'da haqiqiy obyekt). languageOptions.globals — eski env o'rnini bosadi (window, document — brauzer global o'zgaruvchilari — ESLint ularni "aniqlanmagan" deb belgilamasin). settings.react.version: "detect" — o'rnatilgan React versiyasini avtomatik aniqlaydi. Qoidalar: react-hooks/rules-of-hooks (error) — hook faqat komponent tepasida chaqirilsin (shart/tsikl ichida emas — 11-QISM — bu haqiqiy bug manbai); react-hooks/exhaustive-deps (warn) — useEffect bog'liqlik massivi to'liqmi (eskirgan qiymat xavfi); jsx-a11y/alt-text (error) — rasmda alt matni (nogironlar uchun — 13-QISM); import/no-cycle — davriy import taqiq (ikki fayl bir-birini import qilishi — chalkash bog'liqlik); import/order — import tartibi izchil. Eng oxirida prettier (eslint-config-prettier) — barcha format qoidalarini o'chiradi (Misol 2 — tartib muhim). Nega bu muhim: React'da eng keng xatolar (hook qoidasi buzilishi, to'liqsiz bog'liqlik massivi) ESLint yadrosida tutilmaydi — faqat react-hooks plagini topadi. Plaginlar loyiha stack'iga qarab tanlanadi — bu React loyiha uchun tavsiya etilgan minimal to'plam. Real vaqtda editor (VS Code ESLint kengaytmasi) bu qoidalarni yozish paytida ko'rsatadi.

5. To'g'ri va noto'g'ri holatlar

1) Format

text

❌ qo'lda format (har kim har xil — chalkash)
✅ Prettier (avtomatik, izchil — 2.3)

2) ESLint + Prettier

text

❌ ikkalasi format (mojaro — 2.3)
✅ eslint-config-prettier (ESLint sifat, Prettier format — Misol 2)

3) Commit

text

❌ qo'lda lint (unutiladi — buzuq kod git'da)
✅ Husky + lint-staged (avtomatik — Misol 3)

4) Hook tezligi

text

❌ butun loyiha (sekin commit)
✅ lint-staged (faqat o'zgargan — 2.5)

5) CI

text

❌ faqat Husky (--no-verify bilan o'tkaziladi)
✅ CI ham (markaziy qatlam — Misol 4)

6) eslint-disable

text

❌ butun fayl / sababsiz (vosita foydasiz)
✅ aniq qoida + sabab + cheklangan (Misol 5)

6. Keng tarqalgan xatolar va yechimlari

Xato 1 — ESLint vs Prettier mojaro

Sababi: ikkalasi format 2.3-bob. Yechimi: eslint-config-prettier (Misol 2).

Xato 2 — Buzuq kod git'da

Sababi: qo'lda lint (unutildi). Yechimi: Husky pre-commit (Misol 3).

Xato 3 — Commit sekin

Sababi: butun loyiha lint 2.5-bob. Yechimi: lint-staged (faqat o'zgargan).

Xato 4 — Juda ko'p ESLint xato

Sababi: har narsa error (demotivatsiya — 2.7). Yechimi: muhimlarini error, qolgani warn (Misol 1).

Xato 5 — Local hook chetlab o'tildi

Sababi: --no-verify yoki Husky yo'q 2.6-bob. Yechimi: CI ham (markaziy — Misol 4).

Xato 6 — eslint-disable hamma joyda

Sababi: qoidani chetlab o'tish 2.7-bob. Yechimi: sababli, cheklangan (Misol 5).

Xato 7 — Tip xatosi ESLint'dan o'tib ketdi

Sababi: ESLint tip tizimini emas, naqshni tekshiradi (2.5.2). Yechimi: tsc --noEmit alohida qadam (CI/pre-push).

Xato 8 — Chalkash commit tarixi

Sababi: commit xabar standartsiz ("WIP", "tuzatdim" — 2.5.1). Yechimi: commitlint + Conventional Commits (commit-msg hook).

Xato 9 — Katta loyihada lint sekin

Sababi: har safar butun loyiha qayta tekshiriladi 2.8-bob. Yechimi: --cache (.eslintcache) + lint-staged.

7. Integratsiya — bu mavzu stack'ning qayerida uchraydi

Toza kod 15.1-bob: ESLint/Prettier — toza kodni avtomatlashtirish.
Code review 15.2-bob: format avtomatik → review mantiqqa 2.7-bob.
Git (4-QISM): Husky — git hooks (commit).
CI/CD 10.9-bob: CI — lint/format/test (markaziy).
TypeScript (7-QISM): ESLint TS qoidalari (@typescript-eslint), tsc --noEmit type-check.
React (11-QISM), qulaylik (13-QISM): react-hooks, jsx-a11y plaginlari (Misol 6).
Xavfsizlik 14.9-bob: ESLint security plugin, secret scan (pre-commit).
Git commit standarti (4-QISM): commitlint — Conventional Commits (commit-msg — 2.5.1).
Monorepo 15.4-bob: umumiy/shared konfiguratsiya, lint task keshi 2.8-bob.

8. Eng yaxshi amaliyotlar (best practices)

Prettier (format) + ESLint (sifat) (alohida vazifa — 2.1).
eslint-config-prettier (mojaro hal — Misol 2).
Husky + lint-staged (commit — tez, avtomatik — Misol 3).
CI ham (markaziy qatlam — --no-verify'dan himoya — Misol 4).
Editor format on save (eng qulay — 2.6).
Muhimlarini error (qolgani warn — demotivatsiya emas — Misol 1).
Jamoa standarti (umumiy konfiguratsiya — 2.7).
eslint-disable sababli (cheklangan — Misol 5).
lint-staged (tez) (faqat o'zgargan — 2.5).
tsc --noEmit (tip tekshiruv — ESLint yetarli emas — 2.5.2).
commitlint (Conventional Commits — o'qiladigan tarix — 2.5.1).
Flat config (yangi loyihada eslint.config.js — 2.2.1).
--cache + shared config (tez + izchil — 2.8).
Bir marta sozla (keyin avtomatik foyda — 2.6).

9. Amaliy loyiha: "Kod Sifati Avtomatlashtirish"

ESLint, Prettier, Husky, lint-staged sozlashni mustahkamlash.

Maqsad

Loyihaga to'liq kod sifati infratuzilmasi: ESLint, Prettier, Husky, lint-staged, CI.

Talablar (requirements)

ESLint: sifat qoidalari (recommended + maxsus — Misol 1).
Prettier: format sozlamasi (.prettierrc — Misol 2).
Mojaro: eslint-config-prettier (Misol 2).
Husky: pre-commit hook (Misol 3).
lint-staged: faqat o'zgargan (Misol 3).
CI: lint/format/type/test (Misol 4).
Editor: format on save + ESLint plugin 2.6-bob.
Scripts: lint, format, format:check (Misol 2).
Balans: muhimlarini error (Misol 1).
Test: buzuq kod commit'ni to'xtatadimi (Misol 3).

Maslahatlar (hint)

eslint-config-prettier (Xato 1).
Husky pre-commit (Xato 2).
lint-staged (Xato 3).
CI ham (Xato 5).
Balans (Xato 4).

"Tayyor" mezonlari (acceptance criteria)

ESLint (sifat).
Prettier (format, mojarosiz).
Husky + lint-staged (commit).
CI (lint/format/test).
Editor (format on save).
Buzuq kod commit'da to'xtaydi.

Yechim kodi ataylab berilmagan — bu loyihani o'zingiz yozib ko'ring.

10. Xulosa va keyingi bobga ko'prik

Bu bobda kod sifati avtomatlashtirishni chuqur o'rgandik:

Vositalar roli (ESLint/Prettier/Husky/lint-staged — 2.1); ESLint (sifat, flat config, plaginlar — 2.2); Prettier (format, .prettierignore, editor — 2.3); Husky (git hooks — 2.4); lint-staged (tez — 2.5); commitlint + type-check (2.5.1–2.5.2); CI/to'liq oqim 2.6-bob; best practices 2.7-bob; performans, shared config, monorepo 2.8-bob; qaysi qoida to'plami 2.9-bob.

Endi siz kod sifatini avtomatlashtirasiz: ESLint (sifat), Prettier (format), Husky + lint-staged (commit), CI (markaziy). Kod izchil, toza, avtomatik (qo'lda emas) — va review format munozarasidan ozod 15.2-bob.

Keyingi bob — 15.4-bob: Monorepo (Turborepo / Nx). Kod sifatini avtomatlashtirishni bildik; endi ko'p loyihani bir joyda boshqarishni ko'ramiz: monorepo (bir repozitoriyda ko'p loyiha/paket — frontend + backend + umumiy kod), Turborepo/Nx (monorepo vositalari — build kesh, bog'liqlik), umumiy kod (shared paketlar), va qachon monorepo. Bu — katta, ko'p qismli loyiha boshqaruvi.

Foydalanilgan rasmiy/ishonchli manbalar

ESLint rasmiy hujjati — flat config (eslint.config.js), qoidalar, plaginlar, migratsiya (.eslintrc → flat)
typescript-eslint — TypeScript qoidalari va parser; eslint-plugin-react, eslint-plugin-react-hooks, eslint-plugin-jsx-a11y, eslint-plugin-import rasmiy hujjatlari
Prettier rasmiy hujjati — sozlash, .prettierignore, ESLint integratsiyasi (eslint-config-prettier)
TypeScript rasmiy hujjati — tsc --noEmit, kompilyator bayroqlari
Husky rasmiy hujjati (v9+) va lint-staged rasmiy hujjati
commitlint va Conventional Commits spetsifikatsiyasi
GitHub Actions rasmiy hujjati — CI workflow, kesh (actions/cache)
VS Code rasmiy hujjati — ESLint/Prettier kengaytmalari, settings.json (format on save)

Ulashish:Telegram'da

O'qiganingizni mustahkamlang

Izohlar (0)

Izoh yozish uchun kiring.

Hozircha izoh yo'q. Birinchi bo'ling!

ESLint, Prettier, Husky va lint-staged — kod sifatini avtomatlashtirish (15.3-bob)

1. Kirish va motivatsiya

2. Nazariya — chuqur tushuntirish

2.1. Nega avtomatlashtirish (vositalar roli)

2.2. ESLint (kod sifati)

2.2.1. Flat config (eslint.config.js) vs eski (.eslintrc)

2.2.2. Plaginlar — ekotizim qoidalari

2.3. Prettier (format)

2.3.1. .prettierignore va editor sozlamalari

2.4. Husky (git hooks)

2.5. lint-staged (faqat o'zgargan)

2.5.1. commitlint — commit xabar standarti (commit-msg hook)

2.5.2. TypeScript type-check (tsc --noEmit)

2.6. CI'da va to'liq sozlash

2.7. Best practices va keng muammolar

2.8. Performans (kesh), jamoa uchun umumiy konfiguratsiya va monorepo

2.9. Qachon qaysi qoida to'plami (Airbnb / Standard / o'z)

3. Sintaksis — sozlash ma'lumotnoma

4. Batafsil misollar

Misol 1 — ESLint sozlash (2.2)

Misol 2 — Prettier + ESLint birga (2.3)

Misol 3 — Husky + lint-staged (2.4, 2.5)

Misol 4 — To'liq CI sozlash (2.6)

Misol 5 — eslint-disable to'g'ri ishlatish (2.7)

Misol 6 — React plaginlari va flat config (2.2.2)

5. To'g'ri va noto'g'ri holatlar

6. Keng tarqalgan xatolar va yechimlari

7. Integratsiya — bu mavzu stack'ning qayerida uchraydi

8. Eng yaxshi amaliyotlar (best practices)

9. Amaliy loyiha: "Kod Sifati Avtomatlashtirish"

Maqsad

Talablar (requirements)

Maslahatlar (hint)

"Tayyor" mezonlari (acceptance criteria)

10. Xulosa va keyingi bobga ko'prik

Foydalanilgan rasmiy/ishonchli manbalar

O'qiganingizni mustahkamlang

Izohlar (0)

2.2.1. Flat config (`eslint.config.js`) vs eski (`.eslintrc`)

2.3.1. `.prettierignore` va editor sozlamalari

2.5.2. TypeScript type-check (`tsc --noEmit`)