Sampai baru-baru ini, di semua proyek di depan, pengembang Dodo Pizza Engineering menggunakan tslint - alat yang berguna yang memberi tahu Anda ketika Anda
mengacaukan kode, membuat ketidakakuratan, membantu mempertahankan kode dengan gaya yang sama dan mengoreksi banyak komentar. Tapi kemudian tslint mengambil dan mati. Di bawah potongan, saya akan memberi tahu Anda mengapa hal itu terjadi, bagaimana berhenti menuangkan air mata ke almarhum dan beralih ke alat eslint, dan juga menunjukkan sesuatu yang sangat intim.
Sebenarnya, semuanya sudah dimulai sejak lama: rilis kernel tslint terakhir sudah di tahun 2016. Dan inilah saat ketika saatnya untuk mulai mengatakan "terakhir," jika seseorang masih mengatakan "terakhir," karena rilis itu benar-benar yang terakhir. Pada 19 Februari 2019, sebuah
pos resmi dirilis untuk menghentikan pengembangan tslint. Di dalamnya, perusahaan pengembangan (omong-omong, ini bahkan bukan Microsoft) sangat menyarankan semua orang untuk beralih ke eslint, karena upaya mereka sekarang akan ditujukan untuk meningkatkan dukungan TypeScript dalam linter ini.
Satu bahasa, satu tumpukan, satu komunitas
Microsoft melihat TypeScript sebagai bahasa pengembangan web utama, yang seharusnya menggantikan Java / ECMA Script. Jelas, tujuan ambisius seperti itu menyiratkan tumpukan alat tunggal untuk seluruh pengembangan front-end. Ini harus sangat menyederhanakan migrasi komunitas JS besar ke TypeScript. Selain jaminan kepercayaan dari Microsoft, eslint memiliki arsitektur yang lebih baik daripada tslint. Misalnya, Anda dapat menghubungkan parser, dan ada lebih banyak pilihan aturan yang terhubung.
Microsoft tidak akan menjadi dirinya sendiri jika itu hanya diinginkan. Apa pun yang kami katakan tentang kualitas perangkat lunak mereka, mereka melakukan alat pengembangan yang hebat (dan, omong-omong, perangkat input). Jadi kali ini mereka tidak datang dengan tangan kosong, tetapi menulis
rencana migrasi . Sesuai dengan rencana ini, pengembangan peraturan tslint telah dihentikan pada 1 Agustus 2019, dan pengembangan tslint itu sendiri akan berhenti pada 1 November 2019. Meskipun, jujur saja, pengembangan telah dihentikan sejak lama (lihat di atas untuk rilis terbaru).
Di sini seharusnya menjadi jelas bagi pembaca bahwa sudah saatnya beralih ke eslint, tidak ada pilihan lain. Untuk mempermanis pil, perlu dikatakan bahwa:
- sementara tslint difokuskan pada TypeScript dengan penekanan yang lebih besar pada penggunaan jenis dan pemeriksaan sintaks yang benar, eslint mencakup semua yang ada di depan, termasuk sintaks komponen Bereaksi;
- eslint memiliki lebih banyak aturan yang telah ditentukan;
- ada aturan (dan plugin) yang memeriksa kode di tingkat blok (duplikasi kode, kompleksitas yang dirasakan, dll.);
- ada plugin yang memeriksa bukan kode sama sekali, tetapi, misalnya, ekspresi reguler.
Secara umum, sepertinya transisi ke linter baru, yang merupakan produk utama, akan membuka seluruh dunia peluang yang sebelumnya tak terlihat bagi kita. Baiklah, mari kita coba!
Tambahkan eslint ke proyek
Saya akan berbicara tentang migrasi aturan di bawah ini. Sementara itu, buat proyek untuk bekerja dengan eslint.
Jika Anda sudah memiliki proyek dengan tslint, maka hapus dulu semua paket yang terkait dengan tslint: tslint sendiri, tslint-react, tslint-config-prettier, dll.
Sekarang tambahkan paket eslint ke proyek (tetapkan semuanya sebagai devDependencies):
- eslint sendiri;
- @ typescript-eslint / parser - engine untuk parsing TypeScript;
- @ typescript-eslint / eslint-plugin - set aturan untuk TypeScript
Eslint pengaturan minimal
Buat file konfigurasi .eslintrc.json. Eslint mendukung banyak format file untuk konfigurasinya, tetapi JSON sepertinya yang paling nyaman. Begini tampilan opsi kerja minimal:
{ // "env": { // "browser": true, // ES6 "es6": true, // ES2017 "es2017": true }, // "extends": [ // eslint "eslint:recommended", // "plugin:@typescript-eslint/eslint-recommended", // TypeScript "plugin:@typescript-eslint/recommended", // TS, "plugin:@typescript-eslint/recommended-requiring-type-checking" ], // "parser": "@typescript-eslint/parser", "parserOptions": { // TS "project": "tsconfig.json", "tsconfigRootDir": ".", }, // TypeScript "plugins": ["@typescript-eslint"], "rules": {} }
Bagian
env memberi tahu eslint tentang opsi proyek Anda. Dalam contoh saya, ini adalah proyek untuk peramban (yaitu kode akan berfungsi di peramban). Tulis untuk Node.JS - set simpul: true. Dua opsi berikut menunjukkan dialek JS yang sedang diuji. Secara umum, kami akan memeriksa kode untuk TypeScript, tetapi jika proyek Anda juga memiliki kode untuk JS, maka jangan lupa untuk mengencangkannya. Bagi kami sendiri, kami memutuskan bahwa kami menetapkan parameter ini ke nilai yang sama dengan target di tsconfig.json.
Tidak ada yang kontroversial tentang set aturan eslint standar, seperti titik koma yang diperlukan di akhir ekspresi atau spasi / tab. Semua aturan bermanfaat secara unik. Anda dapat melihat aturan apa dan dengan level apa yang disertakan di
sini .
Baris berikutnya Anda perlu
menonaktifkan setengah aturan. Ini diperlukan karena mereka tidak bekerja dengan TypeScript dan alih-alih bekerja secara normal mereka akan membuang banyak kesalahan.
Maka Anda harus menghubungkan aturan yang direkomendasikan dari TypeScript di tas terpisah. Di sini Anda perlu diingat bahwa
aturan sintaksis umum (seperti melarang var) akan berfungsi seperti itu.
Tetapi untuk aturan yang
menggunakan tipe TS (misalnya, @ typescript-eslint / no-not-type-assertion), mesin TypeScript diperlukan. Dan mesin akan membutuhkan file tsconfig.json, jalan yang harus ditentukan.
Di tsconfig.json, kami di Dodo Pizza Engineering biasanya menentukan kecualikan dan membuang tes sehingga tes tersebut tidak sesuai dengan proyek. Tetapi agar eslint tidak berfungsi, Anda harus menentukan dan memasukkan. Artinya, semua file yang perlu disalin harus dimasukkan secara eksplisit dalam proyek. Tanpa ini, eslint akan bersumpah pada setiap file yang ditemukannya: "File itu tidak ada dalam proyek, saya tidak akan melakukan apa-apa, saya akan melakukan banyak kesalahan." Ada opsi tanpa menentukan file proyek secara eksplisit - setel
createDefaultProgram: true parameter
createDefaultProgram: true . Ini, pada intinya, berarti: "Semua yang Anda temukan adalah Parsi." Tetapi pengembang sangat menyarankan untuk tidak melakukannya karena penurunan kinerja yang signifikan.
Jika Anda menggunakan ForkTsCheckerWebpackPlugin untuk memproses file TypeScript, kemudian ganti
tslint: true dengan
eslint: true dalam parameternya (di webpack.config.ts).
Anda juga perlu menyiapkan peluncuran linter dari baris perintah. Sebelum itu, tambahkan nilai ini ke bagian skrip di
package.json :
"eslint": "eslint --cache --ext .js,.jsx,.ts,.tsx src", "eslint:dump": "eslint --print-config ./.eslintrc.json",
Baris pertama baru memulai pemeriksaan eslint tanpa membangun proyek. Yang kedua menampilkan pengaturan eslint saat ini, yang memungkinkan Anda melihat pengaturan untuk parameter aturan.
Dalam opsi ini, eslint sudah akan bekerja di proyek dan bahkan menangkap beberapa tiang tembok: mendefinisikan ulang global, variabel yang tidak digunakan, dll.
Menyiapkan Kode Visual Studio
Setelah Anda melakukan semua ini, Anda sudah dapat memulai linter dari baris perintah. Ini juga akan diluncurkan secara implisit ketika membangun proyek. Tetapi dalam Visual Studio Code kita tidak akan melihat komentar dari linter. Bagaimana bisa ?!
Ada plugin eslint untuk studio (dbaeumer.vscode-eslint), itu harus diinstal. Setelah itu, tidak ada yang akan berhasil, tidak ada yang akan ditekankan dan diperbaiki. Mengapa Karena plugin memiliki konfigurasi, yang mengatakan bahwa Anda hanya perlu bekerja dalam file JavaScript.
Pengaturan licik ini tidak dibuat di UI, jadi Anda harus masuk ke file pengaturan studio dan secara manual menambahkan bahasa yang Anda butuhkan ke parameter eslint.validate. Daftar lengkap bahasa dapat ditemukan di isi dokumentasi studio. Seperti apa pengaturan ini dengan kami:
"eslint.validate": [ "javascript", "javascriptreact", "typescriptreact", "typescript", ],
Setelah itu, restart studio dan semuanya akhirnya akan mulai berfungsi.
Sekarang tinggal mengkonfigurasi aturan
Proyek sudah diatur. Sekarang tentang aturan, karena pada contoh di atas daftar aturan kosong.
Saya harus mengatakan bahwa tslint tidak menghentikan kami untuk mengacaukan kode yang benar secara formal. Misalnya, lupakan menunggu. Eslint dapat menemukan kesalahan semantik seperti itu dan bersumpah pada mereka: untuk menginformasikan bahwa nilai kembali adalah Janji, tetapi untuk itu, untuk beberapa alasan, menunggu tidak ditulis. Ini juga termasuk masalah gaya kompleksitas menengah: penggunaan lambda atau fungsi, dll, yang tidak lagi bisa dilakukan oleh Prettier.
Mengenai aturan sederhana: posisi kurung, tab vs spasi, dll., diyakini bahwa mereka harus diberikan kepada Prettier atau paket serupa. Tetapi dalam linter mereka harus dibiarkan tetap: ini adalah perbatasan terakhir, yang masih mampu menghentikan pengembang lalai perakitan proyek yang jatuh. Selain itu, baris ini dapat otomatis: misalnya,
husky , memungkinkan Anda untuk memulai linter secara otomatis untuk setiap komit.
Kami memutuskan
untuk tidak melakukan migrasi dari set aturan tslint yang kami miliki. Dan buat set Anda sendiri dari awal.
Ada set aturan standar untuk eslint:
- ESLint Recommended adalah seperangkat aturan netral yang dibuat dengan ide tidak menelurkan holivar. Hanya pemeriksaan yang jelas diperlukan yang dimasukkan: variabel yang tidak digunakan, dll. Semua set berikutnya memperpanjang yang ini.
- Google - sudah ada alasan untuk holivar: untuk indentasi ada spasi, diperlukan tanda titik koma.
- AirBnB - Ada juga aturan gaya yang ketat, termasuk titik koma wajib.
- Standart - titik koma dilarang di sini, tetapi koma juga dilarang.
Kami tidak menyukai paket yang sudah jadi. Ini mungkin terdengar aneh, tetapi penting bagi kita untuk beralih ke film baru, menghindari perang gaya. Jika kita menulis seperti ini di mana-mana (tab, tanpa titik koma, trailing koma adalah wajib), maka biarkan tetap demikian - yang utama adalah sama di semua proyek.
Seks yang dijanjikan: seperangkat aturannya sendiri
Jujur, untuk menunjukkan set aturan eslint Anda seperti seorang gadis yang menunjukkan payudara: tidak ada lagi rahasia. Sudah lama saya berpikir apakah perlu melakukan ini. Tetapi, setelah berkonsultasi dengan sesama gadis, saya memutuskan bahwa itu sepadan.
Saya akan mulai dengan plugin yang kami gunakan:
- reaksi - memeriksa kode komponen reaksi. Kumpulan aturan dasar plus kita. Dari yang penting: kita tenggelam untuk komponen fungsional murni;
- react-hooks - aturan dari pengembang reaksi tentang penggunaan hook;
- janji - memeriksa kesalahan umum saat menggunakan Janji. Ini bekerja agak aneh dengan kode TypeScript. Dari yang penting: kami mencoba menggunakan Janji di mana-mana dan tidak menggunakan panggilan balik lalu / menangkap karena keterbacaan kode yang lebih baik;
- optimal-regex adalah plugin menyenangkan yang memberikan tips untuk meningkatkan ekspresi reguler. Tidak terlalu berguna, karena regexp kita punya sedikit. Tetapi jauh dari semua memiliki sihir regexp. Jadi ini berguna, tetapi tidak banyak bertanya;
- sonarjs adalah plugin api dengan memeriksa kompleksitas kode dan kesalahan refactoring khas. Yang pertama adalah hal yang lucu: plugin mengevaluasi kompleksitas yang dirasakan dari kode dan memberikan saran ketika itu layak menyederhanakan kode. Pencarian untuk kesalahan refactoring sering juga memungkinkan penyederhanaan kode atau, setidaknya, meningkatkan keterbacaan;
- @ typescript-eslint - aturan eslint untuk memeriksa kode TypeScript. Dan satu set untuk menonaktifkan aturan dasar yang tidak kompatibel dengan TS.
Seluruh file aturan kami ada di
sini . Saya perhatikan bahwa ini bukan dogma dan diperbarui karena menyesuaikan dengan proyek.