Dasturlash kitobi/15-QISM — Kasbiy konikmalar42 daqiqa

15.3-bob: ESLint, Prettier, Husky va lint-staged

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 — ogohlantir
      "@typescript-eslint/no-explicit-any": "warn",     // any — ogohlantir (7-QISM)
    },
  },
  { ignores: ["dist/", "node_modules/", ".next/"] },    // tekshirma
];

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 tekshir).

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)

Izohlar (0)

Izoh yozish uchun kiring.

Hozircha izoh yo'q. Birinchi bo'ling!

15.3-bob: ESLint, Prettier, Husky va lint-staged

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

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`)