Linter formatterdan nimasi bilan farq qiladi?

JuniorFrontend vositalari #tooling #eslint #prettier

Savol

Linter (ESLint) bilan formatter (Prettier) o'rtasidagi farq nimada va nega ularni birga ishlatish kerak?

Qisqa javob

Linter kodning AST'ini tahlil qiladi va potensial xatolar hamda stil qoidalari buzilishlarini izlaydi (masalan, ishlatilmagan o'zgaruvchi, == o'rniga ===), lekin kod vizual jihatdan qanday ko'rinishi kerakligini o'zi hal qilmaydi. Formatter esa umuman xato izlamaydi — u qat'iy belgilangan qoidalar bo'yicha (chekinishlar, qo'shtirnoqlar, qator ko'chirishlar) kodni deterministik tarzda qayta formatlaydi, bu mohiyatan muhokama qilinmaydi.

Batafsil javob

ESLint (linter):

  • Kodni ASTga (abstrakt sintaktik daraxt) parse qiladi va uning ustidan qoidalar (rules) to'plamini o'tkazadi.
  • Qoidalar ikki turda bo'ladi: haqiqiy baglarni topadigan (no-undef — e'lon qilinmagan o'zgaruvchidan foydalanish, no-unreachable — returndan keyingi kod, React'da exhaustive-deps) va stil/sifatni kuzatadigan (no-var, eqeqeq, funksiyalar murakkabligini cheklash).
  • Ko'pgina qoidalar avtomatik tuzatiladi (eslint --fix), lekin hammasi emas — ba'zilari inson qarorini talab qiladi (masalan, "bu o'zgaruvchi ishlatilmayapti — uni o'chiring yoki ishlating").
  • eslint.config.js (flat config) orqali konfiguratsiya qilinadi, qoidalar to'plamlari (eslint:recommended, plugin:vue/recommended va h.k.) va aniq stek uchun pluginlar bilan.

Prettier (formatter):

  • Kod semantikasini tahlil qilmaydi va baglarni izlamaydi — u kodni parse qiladi va qayta chop etadi, kanonik shaklda.
  • Ataylab kam sozlanadigan ("opinionated") — minimal opsiyalar (qator kengligi, qo'shtirnoqlar, nuqta-vergul), code review'da jamoada formatlash stili haqidagi bahslarni to'xtatish uchun.
  • Idempotent: necha marta ishga tushirilmasin — natija bir xil bo'ladi.

Nega birga: ESLint "yomon/xato kod yozishga yo'l qo'yma" uchun javobgar, Prettier esa "repozitoriydagi barcha kod kim yozganidan qat'i nazar bir xil ko'rinadi" uchun. Agar formatlashni ESLint-qoidalariga topshirilsa (avvallari eslint-plugin-prettier yoki indent kabi stil qoidalari orqali qilinganidek), ular Prettier bilan ziddiyatga kirib, CI'da ortiqcha xatolar yaratadi. Zamonaviy yondashuv — javobgarlikni ajratish: ESLint faqat kod sifati uchun, Prettier faqat formatlash uchun, ESLint'ning stil qoidalari esa eslint-config-prettier orqali o'chiriladi.

Biome — Rust'dagi yangiroq alternativa, linter va formatterni Node.js bog'liqliklarisiz bitta binar faylda birlashtiradi. Katta kod bazalarida bir necha barobar yuqori tezlik beradi va ikkita alohida vositaning versiyalarini sinxronlashtirishni talab qilmaydi, garchi plagin ekotizimi hozircha ESLint'nikidan kichikroq bo'lsa ham.

Misol

// eslint.config.js — linter: xatolarni izlaydi, formatlash bilan shug'ullanmaydi
import js from '@eslint/js'

export default [
  js.configs.recommended,
  {
    rules: {
      'no-unused-vars': 'warn',
      eqeqeq: 'error',       // == o'rniga === talab qilish
      'no-console': 'warn',
    },
  },
]
// .prettierrc — formatter: faqat kodning tashqi ko'rinishi
{
  "semi": false,
  "singleQuote": true,
  "printWidth": 100,
  "trailingComma": "es5"
}
# CI'dagi odatiy pipeline: avval lint (baglar), keyin format-tekshiruv (stil)
eslint . --max-warnings=0
prettier --check .

Qo'shimcha savollar

  • Nega Prettier bilan birga formatlash uchun ESLint qoidalarini ishlatmaslik kerak?
  • husky + lint-staged'ni commit'dan oldin lint va formatlash ishga tushishi uchun qanday sozlash mumkin?
  • Katta mavjud loyihada ESLint+Prettier'dan Biome'ga o'tishning qanday kelishuvi (trade-off) bor?