Html5-boilerplate: RFC: Migrasi ke ESLint

Siapa saja? Saya puas meninggalkan status quo. ESLint memang bagus, tetapi saya harus diyakinkan untuk membuat perubahan (dan kemudian seseorang harus _membuat_ perubahan dalam PR.) Saya akan membiarkan ini terbuka selama seminggu lagi dan jika tidak ada tindakan, saya akan menutupnya.

Saya bisa PR untuk ini. ESLint bisa dibilang salah satu alat yang paling banyak digunakan di ekosistem javascript.

http://www.npmtrends.com/eslint-vs-jshint

@roblarsen Saya benar-benar berada di pihak @amilajack dalam hal ini,
Saya membuat perbandingan singkat antara keduanya dengan beberapa data yang saya kumpulkan dari Web jika Anda ingin melihatnya.

Terima kasih teman-teman. Itu bagus. Ada lagi yang ingin ikut campur?

@amilajack terima kasih atas tawarannya ke PR. Itu sangat dihargai.

@roblarsen Sama- sama!
@amilajack Jangan ragu untuk

@amilajack Apakah Anda masih mengerjakan ini?

@ryzokuken Ada PR terbuka yang perlu saya lihat dan gabungkan. # 1930

Saya akan merekomendasikan untuk melihat Standar yang merupakan tambahan di atas ESLint, dan yang cukup populer. Sejujurnya, ini melegakan karena akhirnya berhenti mempertahankan konfigurasi ESLint ...

@ArmorDarks Meskipun saya suka gaya Standar, menurut saya tidak baik memaksa orang lain untuk mengikutinya. Terutama pengembang yang tidak memiliki banyak pengetahuan atau pengalaman, karena kode mereka dapat menyebabkan kesalahan waktu proses yang tidak terduga dan menyebabkan masalah lebih lanjut, bahkan menyebabkan peningkatan jumlah masalah untuk proyek tersebut.

Meskipun saya menyukai fleksibilitas bahasa pemrograman, keuntungan seperti itu ada harganya, dan pertanyaannya adalah apakah kita bersedia membayar harga itu. Aturan yang lebih ketat hampir selalu membuat kode lebih mudah dipahami dan sebagai konsekuensinya lebih dapat diandalkan, bahkan saat proyek berkembang.

Selain itu, titik koma menang berdasarkan popularitas, mengambil panduan gaya JavaScript Airbnb sebagai contoh: salah satu repositori paling berbintang di GitHub dan nomor unduhan yang lebih tinggi di NPM. [1] [2] [3] [4]

Selain itu, kita perlu memperbarui semua file JavaScript, karena semuanya sudah menggunakan titik koma. [5] [6]

Oleh karena itu, saya tidak percaya topik ini sepadan dengan bikeshedding .

Referensi:

[1] https://github.com/airbnb/javascript
[2] https://www.npmjs.com/package/eslint-config-airbnb-base
[3] https://www.npmjs.com/package/eslint-config-airbnb
[4] https://www.npmjs.com/package/eslint-config-standard
[5] https://github.com/h5bp/html5-boilerplate/blob/master/gulpfile.babel.js
[6] https://github.com/h5bp/html5-boilerplate/blob/master/src/js/plugins.js

Itu semua akan bermuara pada perselisihan codestyle. Saya hanya mengusulkan alternatif yang teruji dalam pertempuran.

Btw, saya harus menyoroti, bahwa tidak peduli dengan opsi apa boilerplate akan digunakan (baik itu ESLint dengan aturan proyek sendiri, baik itu konfigurasi ESLint yang populer, seperti airbnb, atau menjadi Standar), _ bagaimanapun juga akan memberlakukan sesuatu pada pengguna untuk diikuti_. Jadi tinggal soal apa sebenarnya yang akan ditegakkan.

Pada titik ini saya ingin beralih ke eslint dengan gangguan sesedikit mungkin. Itu termasuk menghilangkan aturan yang ada yang kami miliki secara grosir tanpa setidaknya diskusi tentang aturan baru apa yang seharusnya (itulah mengapa PR yang ada untuk eslint adalah DOA.)

Saya akan mati di atas titik koma, misalnya.

Sebagai catatan: konsumen sebenarnya dari kumpulan aturan terbatas pada pengelola dan siapa saja yang dengan cermat membuat PR dan benar-benar menguji kode mereka. Kami tidak akan mengirimkan eslintrc di dist. Manfaat nyata, dalam hal proyek, adalah kita _melakukannya_ dan dapat berfungsi sebagai contoh seperti apa pengembang web yang baik seharusnya.

Saya akan mati di atas titik koma, misalnya.

Itu hanya beberapa pukulan dengan regex, lho. Tetapi apakah menggunakannya atau tidak bagi sebagian orang memang tampaknya menjadi tema yang menyakitkan ...

Kami tidak akan mengirimkan eslintrc di dist. Manfaat nyata, dalam hal proyek, adalah kami melakukannya dan dapat berfungsi sebagai contoh seperti apa pengembang web yang baik seharusnya.

Namun Anda mengirimkan kode JS, yang akan disertakan dalam proyek lain, yang nantinya akan diberi lint, dan orang akan dipaksa atau mengeditnya agar sesuai dengan aturan mereka, atau menggunakan aturan HTML5Boilerplate. Itulah mengapa JS harus sedekat mungkin dengan standar komunitas JS, dan menurut saya membuat beberapa perubahan yang diperlukan pada aturan dan gaya kode tidak dapat dihindari. Dan sebenarnya tidak terlalu bermasalah - Standard dan ESLint dengan --fix akan secara otomatis memperbaiki sebagian besar kesalahan aturan yang diperkenalkan.

Masalah sebenarnya adalah apa yang harus dipertimbangkan standar komunitas di dunia JS.

Poin bagus. Ada baiknya untuk diingatkan tentang efek hilir bahkan dari sejumlah kecil JS yang kami kirimkan.

Dan untuk memperjelas, saya tidak menentang melakukan perubahan. Yang tidak ingin saya lakukan adalah membuat perubahan besar-besaran tanpa diskusi (jadi terima kasih telah menjadi bagian dari diskusi 👍) Meskipun saya agak putus asa untuk mengeluarkan 6.0 saat ini, saya biasanya tidak terburu-buru untuk melakukan perubahan di sini kecuali perubahan yang tepat.

Salah satu opsinya adalah menerapkan eslint:recommended config yang melaporkan masalah umum, tetapi tidak benar-benar memaksakan preferensi gaya. Dalam hal ini, ESLint hanya berfungsi untuk mencegah kesalahan dan bug. Ini benar-benar semacam konfigurasi minimal yang masuk akal.

Satu-satunya aturan terkait gaya yang akan saya usulkan untuk ditambahkan dalam kasus itu adalah yang ada di .editorconfig : tidak ada spasi kosong, 4 indentasi spasi, dan baris baru terakhir.

4 indentasi spasi

Sekadar informasi, tidak ada lagi gaya kode populer yang menggunakan 4 spasi indentasi.

https://github.com/h5bp/html5-boilerplate/issues/1913#issuecomment -377298563 (eslint: merekomendasikan) terdengar bagus, meskipun saya memiliki preferensi pribadi untuk https://github.com/h5bp/html5-boilerplate/ masalah / 1913 # penerbitan -318050971 (StandardJS).

Bercanda: https://github.com/christophwitzko/semicolon-indent#semicolon -indent

Saya dengan Standard juga, karena mereka tidak hanya mempertahankan konfigurasi yang baik dengan validasi melalui komunitas tetapi juga mengirimkan tambahan teruji yang sangat baik di atas ESLint.

Tapi agar adil, saya juga harus menyebutkan lebih cantik . Padahal, suara saya masih mendukung Standar.

Pengingat dari awal diskusi

Saya akan mati di atas titik koma, misalnya.

Bayangkan bahwa itu adalah game yang bertahan, dan seperti kita di tahun 2005 memutuskan tab vs spasi.

Btw, perlu disebutkan hal tentang Prettier - itu harus dipasangkan dengan konfigurasi ESLint yang baik, karena sebagian besar semua pemeliharaan Prettier adalah gaya kode, sementara konfigurasi ESLint (dan terutama yang Standar) mencakup juga banyak praktik baik atau buruk non-gaya.