blog

ESLint va Prettier bilan kod uslubini bir xil qilish

NEXTREE.

• 6 min read
ESLint va Prettier bilan kod uslubini bir xil qilish

1. Fonda 

Agar avvalgi maqolada monorepo asosidagi jismoniy tuzilma dizayni haqida gapirgan bo'lsak, endi esa uni ishlab chiqayotgan dasturchilar o'rtasida kod yozish qoidalarini birlashtirish usullari haqida gaplashmoqchiman.

Loyihaning hajmi kattalashgan sayin bir xil faylni bir nechta dasturchi tahrir qilish holatlari ko'paydi va keraksiz Git diff-lar doimiy ravishda lug'atga tushayotganida, tabintroducing va qo‘shiq stilidagi farqlar tufayli yuzaga kelgan.

Kompaniya ichidagi viki (Wiki) orqali yo'riqnomalarni tuzish usuli bunday muammolarni hal qilishda cheklovlarga ega edi va dasturiy ta'minot masalalari yaratilgandek, kod masalasida xato qilmasdan qoidalarni avtomatik tarzda kiritishni talab etadigan tizimga ehtiyoj bor edi.

Ushbu maqolada Vue 3 va TypeScript muhitida ESLint va Prettier yordamida kod konvensiyasini o'rnatish jarayonini va VS Code·IntelliJ muhitida bir xil qoidalarni qo'llash strategiysini baham ko'ramiz.

2. ESLint va Prettier rolini ajratish

Ushbu muammolarni hal qilish uchun avvalo ESLint va Prettier rollarini aniq ajratish zarur edi.

ESLint kod sifatini tekshirish vositasi bo'lib, ishlatilmayotgan o'zgaruvchilar, potensial xatoliklar tug'ma shablonlar, noto'g'ri kod tuzilishi va h.k.ni aniqlaydi.
Aksincha, Prettier kod formatini bir xilda saqlash vositasi bo'lib, tabintroducing, qatorlar o'zgartirish, qo'shni usuli kabi vizual qoidalarni avtomatik ravishda tartibga soladi.

Ikkala vositani birga ishlatganda eng ko'p uchraydigan muammo - qoidalar to'qnashuvidir. ESLint ham ba'zi stil qoidalarini o'z ichiga olgani uchun Prettier bilan bir xil maydonda bir-biridan boshqacha fikrlay oladi.

Buni hal qilish uchun ushbu loyiha plugin:prettier/recommended dan foydalanib, Prettier natijasini ESLint ishga tushirish jarayonida ham tekshirish imkonini yaratdik. Bu orqali nafaqat kod sifatini tekshirish, balki formatlash muammolarini tekshirish imkoniyatiga ega bo'ldik.

Loyihada qo'llangan ESLint sozlamalari misoli quyidagicha.

// .eslintrc
{
  "root": true,
  "env": {
    "node": true,
    "browser": true,
    "es2021": true
  },
  "parser": "vue-eslint-parser",
  "parserOptions": {
    "parser": "@typescript-eslint/parser",
    "ecmaVersion": "latest",
    "sourceType": "module"
  },
  "extends": [
    "plugin:@typescript-eslint/recommended",
    "plugin:vue/vue3-recommended", // Vue 3 환경에서 권장되는 규칙 적용
    "plugin:prettier/recommended"
  ],
  "rules": {
    "vue/multi-word-component-names": "off", // 단일 단어 컴포넌트명 허용
    "no-console": "warn",
    "@typescript-eslint/no-explicit-any": "off"
  }
}

Shuni ta'kidlash joizki, ushbu misol .eslintrc asosidagi Legacy Config muhitida yozilgan. Loyihada ishlatilayotgan eslint-plugin-vue versiyasiga qarab plugin:vue/vue3-recommended yoki plugin:vue/recommended dan foydalanish mumkin.

Shuningdek, ESLint 9 dan yuqori versiyalarda Flat Config (eslint.config.js) dan foydalanish tavsiya etiladi, shuning uchun yangi loyiha boshlab, rasmiy hujjatni ham ko'rib chiqish maqsadga muvofiqdir.

3. Loyihaning umumiy qoidalarini tuzish

Loyihada EditorConfig'ni qo'llab-quvvatlaydigan tahrirlovchi bir xil asosiy qoidalarni bajarishi uchun .editorconfig qo'shildi.

Xususan, end_of_line = lf sozlamasi Windows va macOS o'rtasidagi qator oxiri shakli farqi (CRLF/LF) sababli yuzaga keladigan keraksiz Git diff'larni kamaytirishga yordam beradi.

Har bir sozlamaning ma'nosi quyidagilardir.

  • indent_style = space: kirish uslubini birlashtirish

  • indent_size = 2: Vue/TS loyihasining asosiy uslubini saqlash

  • end_of_line = lf: OS'lar o'rtasida qator oxirlarining to'qnashuvini bartaraf etish

  • insert_final_newline = true: fayl oxirida yangi qatorni ta'minlash

  • trim_trailing_whitespace = true: keraksiz bo'shliqlarni olib tashlash

EditorConfig sozlamalari quyidagilardir.

# .editorconfig
root = true

[*]
charset = utf-8
indent_style = space
indent_size = 2
end_of_line = lf
insert_final_newline = true
trim_trailing_whitespace = true

4. IDE muhitini sinkronizatsiya qilish

Qoidalarni belgilashga qaramay, IDE'da bir xil qo'llanmasa, ahamiyati kamayadi. Aslida, VS Code va IntelliJ (WebStorm kiritilgan) aralash foydalanish muhitida formatlash farqi tufayli Git diff muammosi doimiy ravishda yuzaga kelgan.

4.1 Muammo sababi

VS Code osonlik bilan Prettier'ni qo'llashga imkon beruvchi kengaytmalar asosida ishlaydi, lekin IntelliJ dastlab o'zining formatlagichini ishlatadi va sozlamalarga qarab Prettier o'rniga IDE formatlagichi ishga tushishi mumkin. Bu esa bir xil kod ham IDE'ga qarab format natijalari farq qilib qolishiga sabab bo'ldi.

4.2 Hal qilish yo'llari

4.2.1 VS Code sozlamalari

VS Code'da saqlashda avtomatik formatlash va ESLint avtomatik tuzatish ishlashi uchun sozlandim.

{
  "editor.formatOnSave": true,
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true
  }
}

E'tibor bering, VS Code va ESLint kengaytmasining versiyasiga qarab source.fixAll.eslint sozlash usuli farq qilishi mumkin, eng yangi muhitda "explicit" foydalanish tavsiya etilishi mumkin.

4.2.2 IntelliJ sozlash

IntelliJ muhitida quyidagicha sozlash bir xil qilindi.

  • Prettier yo'lini loyiha node_modules asosida ko'rsatish

  • Kod reformatlashda Prettier'ni majburiy qilish

  • Saqlashda formatlashni IDE formatlovchisi o'rniga Prettier'ga topshirish

Bu sozlama orqali IDElar orasidagi formatlash farqini minimal darajaga tushirish mumkin bo'ldi.

5. Vue SFC parselash xatoliklari sabablari va yechimlar

Dastlabki tadbirda Vue 3 Single File Component (SFC, .vue) ichida ESLint parselash xatosi yuzaga keldi. Ayniqsa <script setup lang="ts"> maydoni to'g'ri talqin qilinmay, TypeScript bilan bog'liq xatoliklar noaniq yuzaga kelayotgan muammo mavjud edi. Bu Vue SFC tuzilmasini tushunmaydigan vue-eslint-parser o'rniga @typescript-eslint/parserdan faqat foydalanish yoki parser tuzishi to'g'ri bog'lanmagan taqdirda yuzaga kelishi mumkin.

Buni hal qilish uchun Vue tuzilmasi va skript maydoni parselashni ajratdik.

// .eslintrc
{
// ...생략
  "parser": "vue-eslint-parser", // 최상단 파서로 Vue 파일의 기본 구조 해석
  "parserOptions": {
    "parser": "@typescript-eslint/parser", // 스크립트 내부 영역만 TS 파서가 담당
    "ecmaVersion": "latest",
    "sourceType": "module"
},
// ...생략
}

Bu sozlamadan keyin .vue fayllarda ham to'g'ri lint ishlaydi va parselash xatosi hal qilindi.

6. Ish tajribasi va cheklovlar

Dastlabki kiritilishida mavjud kod bazasida 200 dan ortiq lint xatoliklari yuzaga keldi. Ayniqsa any foydalanish, console.log, Vue komponent nomlash qoidalari buzilishi asosiy sabablardan biri edi. Barcha qoidalarni Error bilan majburiy qilib qo'yish, rivojlanish tezligiga ta'sir ko'rsatishi mumkin, shuning uchun dastlab ba'zi qoidalarni warn yoki off qilib sozlash orqali bosqichma-bosqich joriy qilish strategiyasini qo'lladik. Shuningdek, console.log debugging jarayonida tez-tez foydalanilganligi sababli dastlab no-console'ni Warning darajasida ishlatdik.

Shuningdek, ushbu bosqichda Husky asosidagi commit tasdiqlashni qo'llamadi. Dastlab lint-staged va Husky orqali commit bosqichini majburiy qilishni ko'rib chiqdik, lekin ustunliklarni mahalliy ishlab chiqish muhitini bir xil qilish va jamoa ichidagi ishlab chiqarish tajribasini barqarorlashtirishga berishga keldik. Kelajakda commit bosqichi yoki CI bosqichida ESLint tasdiqlashni qo'shib, ishlab chiqish muhitlaridagi farqlarga ta'sir qilmaydigan kod sifatini tasdiqlash tuzilmasini kengaytirishni rejalashtirmoqdamiz.

7. Xulosa

ESLint va Prettier ni qoʻllaganimizdan soʻng eng sezilarli oʻzgarish kod koʻrib chiqish usuli edi. Funksiya bilan toʻgʻridan-toʻgʻri bogʻliq boʻlmagan uslub oʻzgartirishlari keskin kamaydi, dasturchilar esa kod formatidan emas, balki biznes mantiqiga koʻproq eʼtibor qaratadigan muhit yaratish imkoniyatiga ega boʻlishdi. Natijada kodni koʻrib chiqish vaqtini va keraksiz oʻzgartirish tarixini kamaytirishga yordam berdi va kod sifatini maʼlum bir darajada saqlash uchun asos yaratish mumkin boʻldi.

Avtomatlashtirilgan kod konventsiyasi muhit katta koʻp tomonlama hamkorlikda barqarorlikni saqlash uchun muhim asos boʻlishi mumkin.

Manbalar

- ESLint Rasmiy Hujjatlari: https://eslint.org/

- Prettier Rasmiy Hujjatlari: https://prettier.io/

- EditorConfig Rasmiy Hujjatlari: https://editorconfig.org/

- Vue ESLint Plagin Rasmiy Hujjatlari: https://eslint.vuejs.org/

Code_Latte

Site footer