Kami baru-baru ini menerbitkan
materi di mana Eric Elliot mengkritik TypeScript. Hari ini kami membawa kepada Anda terjemahan dari artikel Kent Dodds. Di sini dia berbicara tentang mengapa PayPal beralih dari Flow ke TypeScript.
Latar belakang
Saya bekerja di PayPal dan saya terlibat dalam pustaka
paypal-scripts , yang merupakan kotak alat yang mengingatkan
react-scripts dari
create-react-app , atau
angular-cli , atau
ember-cli . Saya
sudah menulis tentang ini. Dasar dari perpustakaan ini adalah gagasan untuk menggabungkan semua alat yang digunakan dalam aplikasi PayPal dan dalam modul yang diterbitkan. Tujuan membuat
paypal-scripts adalah untuk mengambil semua dependensi pengembangan,
devDependencies , dari
package.json , semua file konfigurasi, dan mengurangi semua ini menjadi satu entri di bagian
devDependencies . Dan, karena semua konfigurasi berada dalam satu paket, selama pembuatannya mereka berpegang pada sudut pandang yang sangat spesifik tentang apa yang baik, agar alat tetap mutakhir, cukup untuk memperbarui hanya satu ketergantungan (sebenarnya -
paypal-scripts ) , pembaruan yang biasanya tidak mengandung sesuatu dalam dirinya sendiri yang dapat mengganggu operasi kode yang bergantung padanya. Akibatnya, cukup untuk mempertahankan satu ketergantungan dan dengan tenang terlibat dalam pengembangan aplikasi.
Selama setahun terakhir, programmer PayPal terbiasa bekerja dengan
paypal-scripts . Di sini, untuk membuat aplikasi baru, cukup klik pada beberapa tombol di antarmuka web, sebagai hasilnya repositori GitHub perusahaan akan dibuat, alat penyebaran proyek, sistem integrasi berkelanjutan, dan sebagainya akan dikonfigurasikan. Repositori yang dibuat secara otomatis didasarkan pada repositori
sample-app .
Baru minggu lalu, itu termasuk tambahan saya, yang dirancang untuk menggunakan
paypal-script di dalamnya. Ini berarti bahwa inti setiap aplikasi baru di PayPal adalah kerangka kerja yang dibangun berdasarkan teknologi dan alat modern, yang pembaruannya tidak perlu dikhawatirkan oleh pengembang aplikasi ini. Antara lain, aplikasi seperti itu akan diketik secara statis menggunakan TypeScript dan diuji menggunakan alat Jest.
Jujur, ini telah menjadi Magnum Opus dalam karier saya. Saya tidak berpikir bahwa suatu hari nanti saya akan dapat mencapai level yang sama di PayPal. Proyek ini memiliki dampak yang sangat besar, dan saya berterima kasih kepada PayPal atas kesempatan untuk mengerjakan sesuatu yang begitu besar.
Jadi, saya memperkenalkan Anda pada urusan, sekarang mari kita bicara tentang TypeScript.
Pada pertengahan Desember, saya berupaya mengintegrasikan
paypal-scripts ke dalam
sample-app . Saya juga bekerja (dan terus bekerja) pada proyek
pp-react , yang merupakan pustaka komponen (tombol, jendela, gaya) yang cocok untuk digunakan kembali. Karena
paypal-scripts mendukung modul yang dapat dipublikasikan, saya menggunakan
react-scripts untuk membuat
pp-react . Sebulan yang lalu, perpustakaan
paypal-scripts menyertakan dukungan untuk
Flow . Dukungan seperti itu sangat mudah ditambahkan ke perpustakaan ini berkat Babel.
Pada tanggal 12 Desember, ketika saya sedang mengerjakan
pp-react dan versi baru dari
sample-app dalam hal dukungan Flow, saya merasa bahwa saya sudah sangat lelah dengan Flow (saya akan membahas ini dengan lebih rinci di bawah) dan membuat keputusan yang tidak terduga. Saya menulis surat kepada seorang
kolega bertanya kepadanya bagaimana dia melihat apa yang akan saya coba untuk membuat TypeScript digunakan dalam aplikasi
sample-app . Dia menjawab: "Ya, lakukanlah." Kemudian saya melakukan survei di saluran
#paypal-scripts Slack, yang ternyata semua pesertanya mendukung ide saya. Bagi saya, semua ini sudah cukup untuk mulai bekerja. Sekitar seminggu kemudian, saya sepenuhnya mengganti
paypal-scripts dari dukungan Flow ke dukungan TypeScript. Sebagian besar waktu ini dihabiskan untuk mengajarkan semua alat untuk mengenali
.ts file
.ts dan
.tsx , dan untuk mengizinkan paket
paypal-scripts untuk mengujinya sendiri, yang ternyata merupakan tugas yang cukup sulit. Kemudian saya menghabiskan beberapa hari bekerja pada PR dalam repositori
sample-app , yang ditujukan untuk menggunakan perpustakaan
paypal-scripts , dan beralih dari file
.js ke
.ts dan. file
tsx . Lalu ada hari libur, dan PR saya disetujui. Akibatnya, sekarang di setiap proyek baru PayPal menggunakan pengetikan TypeScript statis.
Tentu saja, setelah seseorang membuat proyek baru, dia dapat melakukan apa pun yang dia inginkan dengannya. Katakanlah, Anda dapat menghapus semua kode boilerplate dan menulisnya di Elm, atau pada yang lain. Ini sangat normal. Tetapi penulis sebagian besar proyek mematuhi teknologi yang digunakan untuk membuatnya karena apa yang disebut "
efek default ".
Mengapa saya pergi ke TypeScript begitu lama?
Pertanyaan yang diajukan dalam judul bagian ini sering ditanyakan oleh penggemar TypeScript. Faktanya adalah bahwa saya sudah lama terbiasa dengan TypeScript, tetapi hubungan saya dengan bahasa ini belum berkembang selama beberapa waktu. Jadi, saya ingat bagaimana, sekitar 2013, seorang kolega menyarankan agar saya menerjemahkan kode dengan volume sekitar 500 ribu baris ke dalam TypeScript. Kemudian saya menolak proposal ini, tetapi saya tidak terlalu menyesalinya, karena pada masa itu TS adalah bahasa yang cukup muda. Dan bahkan saya pernah mewawancarai
Anders Halesberg , pencipta TypeScript.
Itu sebabnya saya tinggal jauh dari TypeScript selama ini.
▍ Alasan nomor 1. Takut menghancurkan lingkungan kerja Babel dan ESLint
Bagi saya, untuk waktu yang sangat lama, keuntungan utama Flow di depan TypeScript adalah Flow lebih baik dikombinasikan dengan alat-alat yang biasa saya gunakan. Secara khusus, saya telah menggunakan Babel dan ESLint selama bertahun-tahun dengan senang hati, saya suka menulis plugin sendiri untuk keduanya (ngomong-ngomong, Anda juga bisa
belajar ini). Saya menyukai kenyataan bahwa ada komunitas besar di sekitar Babel dan ESLint. Akibatnya, saya pasti tidak mau menolak mereka. Faktanya, ini berlanjut sampai peristiwa baru-baru ini, karena jika saya berencana untuk meninggalkan TypeScript dengan kepala saya, saya harus meninggalkan keduanya. Tentu saja, di dunia TypeScript ada yang namanya TSLint, tetapi komunitas ESLint jauh lebih besar.
Di Flow, saya terutama menyukai kenyataan bahwa untuk memasukkannya ke dalam alur kerja Anda, Anda hanya perlu melakukan beberapa langkah sederhana:
- Penting untuk menghubungkan preset dengan dukungan untuk sintaks yang sesuai ke Babel.
- Anda perlu menambahkan konstruksi
// @flow ke awal setiap file, jenis pemeriksaan yang ingin Anda atur (ada plugin untuk ESLint yang memungkinkan Anda memeriksa ini). - Tambahkan skrip ke proyek yang memungkinkan Anda menjalankan Flow untuk memeriksa jenis-jenis dalam basis kode.
Saya sangat menyukai kenyataan bahwa jenis pengecekan (menggunakan Flow) dan proyek pembangunan (menggunakan Babel, Webpack atau Rollup) terpisah. Saya tidak ingin menghubungkan hidup saya dengan TypeScript, khususnya, karena kompilernya, dalam hal apa pun, tidak akan mengerti plugin untuk Babel dari pengembangan saya sendiri. Dan juga - karena saya memiliki Flow - alat yang lumayan.
Sekarang semuanya berjalan seperti biasa. Berkat Babel 7 (khususnya, kita berbicara tentang
skrip @ babel / preset ), Anda dapat menyimpan alat yang sudah dikenal dan, di samping itu, mendapatkan sebagian besar fitur dari TypeScript yang Anda inginkan. Masalah utama adalah membuat alat menerima file dengan ekstensi.
ts dan
.tsx , tetapi, untungnya, masalah ini terpecahkan.
▍ Alasan nomor 2. Kontributor harus belajar TypeScript untuk berkontribusi pada proyek.
Saya terutama berbicara tentang open source, tetapi kebutuhan untuk TypeScript untuk dikembangkan oleh mereka yang ingin berkontribusi pada proyek juga berlaku untuk apa yang saya lakukan di tempat kerja. Pada saat yang sama, saya selalu percaya bahwa proyek kerja harus diketik, dan ini dicapai melalui Flow. Saya mencoba untuk tidak menggunakan Flow dalam proyek open source saya, karena mereka yang memutuskan untuk bergabung dengan mereka harus mempelajari Flow. Saya sendiri selalu membicarakan hal ini, tetapi, secara tidak sadar, saya selalu mengutip tandingan, yang terdiri dari fakta bahwa mengetik, pada intinya, hanyalah bentuk pengujian lain, tetapi mereka yang ingin berkontribusi ke open source harus mencari tahu. dengan pengujian.
Sejujurnya, penolakan untuk menggunakan teknologi tertentu dalam open source hanya karena kontributor potensial mungkin tidak memilikinya, menurut saya alasan yang buruk untuk tidak menggunakan teknologi ini. Dan, karena semakin banyak programmer yang menguasai TypeScript, saya pikir mungkin setelah beberapa saat saya akan menulis di TS dan proyek sumber terbuka saya.
▍ Alasan nomor 3. Sistem Inferensi Tipe Aliran Yang Kuat
Saya membaca posting
ini , dan saya sangat menyukainya. Terutama baris terakhirnya, yang menurutnya saat menggunakan tipe Flow ditambahkan untuk membuat pesan kesalahan lebih menyenangkan, dan bukan untuk mengidentifikasi mereka.
Begitulah. Saat ini, Flow memiliki sistem inferensi tipe yang lebih kuat daripada TypeScript, dan ini mendorong saya.
▍ Alasan nomor 4. Flow, seperti React, berasal dari Facebook
Saya akan berdosa melawan kebenaran jika saya mengatakan bahwa saya tidak menyerah pada kesalahpahaman yang sangat luas bahwa saya percaya bahwa jika sebuah perusahaan melakukan sesuatu yang besar, maka segala hal lain yang dilakukannya akan secara otomatis berada pada tingkat yang sama. Ini sama sekali tidak dijamin. Saya tidak perlu menambahkan apa pun di sini.
▍ Alasan nomor 5. Fanatik TypeScript
Saya pikir semua orang tahu bahwa jika seseorang benar-benar terpesona oleh teknologi tertentu, maka dia, tanpa henti, memberi tahu semua orang di sekitarnya tentang hal itu. Adakah yang menggunakan
vim di sini ? Dan penganut TypeScript tidak terkecuali.
Omong-omong, komunitas TypeScript penuh dengan orang-orang hebat. Baik hati, mau membantu, antusias, ramah. Tapi saya harus bertemu dengan pecinta TS seperti itu yang akan memanggil orang bodoh hanya karena dia tidak menggunakan TypeScript, atau tidak memahaminya, atau menggunakan sesuatu yang lain. Mereka menunjukkan kurangnya kemampuan untuk memahami lawan bicara, dan posisi mereka memberikan keangkuhan. Saya bukan komunitas yang ingin saya ikuti. Maksud saya, antusiasme yang disebabkan oleh teknologi yang dipilih oleh seseorang itu luar biasa, tetapi jika terlalu jauh penggemar teknologi ini mulai menindas mereka yang memilih sesuatu yang lain, itu sudah
sangat menyedihkan .
Saya masih memiliki beberapa kekhawatiran tentang ini. Tetapi saya berharap bahwa bersama kita akan membuat komunitas TypeScript lebih positif.
Sekarang saya telah berbicara tentang alasan mengapa saya tidak terburu-buru untuk beralih ke TypeScript, saya akan berbicara tentang apa yang tidak cocok untuk saya di Flow.
Masalah Aliran
Seperti yang saya katakan, pada titik tertentu saya sangat lelah dengan Flow. Inilah salah satu
tweet di mana saya berbagi salah satu masalah utama yang saya temui saat bekerja dengan Flow. Itu terdiri dari fakta bahwa agar Flow bekerja, perlu secara teratur, setelah awal yang gagal, untuk menghentikannya, dan kemudian memulainya lagi. Berikut ini
tweet saya tentang malfungsi Flow.
Saya akhirnya diusir dari Flow dengan secara teratur menimbulkan masalah dengan keandalannya. Plugin untuk editor bekerja, sehingga untuk berbicara, dengan berbagai tingkat keberhasilan (saya harus mengakui bahwa saya tidak bekerja dengan Nuclide, dan mungkin, jika saya mencobanya, hidup saya akan berubah berbeda, tetapi saya mencoba untuk bekerja dengan Flow in Atom dan dalam VSCode), saya terus-menerus dihadapkan dengan beberapa keanehan. Ini sangat menjengkelkan karena merusak kepercayaan saya pada sistem kontrol tipe yang saya gunakan.
Ketika saya, pada bulan November, melihat tweet
ini , dia mengungkapkan apa yang sudah saya pikirkan; sebuah cerita pendek tentang beralih dari Flow ke TypeScript bertepatan dengan visi saya tentang situasi. Jujur, saya tidak bisa berhenti berpikir tentang cara yang benar mengambil TypeScript. Sebagai hasilnya, saya melakukan hal itu dan saya sangat senang karenanya.
Tanya Jawab
▍ Mengapa kamu tidak menggunakan TSLint?
Bahkan, saya menerapkan dukungan
TSLint dalam
paypal-script . Ini adalah salah satu skrip pertama yang saya peroleh. Saya akan memutuskan apakah akan menggunakan TSLint atau ESLint berdasarkan apakah proyek tersebut memiliki file
tsconfig.json . Tetapi kemudian saya ingat bahwa kami memiliki beberapa plugin ESLint dari desain kami sendiri (misalnya, untuk memeriksa internasionalisasi), yang saya tidak ingin buang waktu menulis ulang sebagai plugin untuk TSLint. Selain itu, antarmuka baris perintah TSLint kurang kuat daripada ESLint, dan tidak cocok untuk bekerja dengan
paypal-scripts . Mungkin setelah beberapa saat saya akan melihat lebih dekat pada TSLint.
Ya, saya ingin mencatat bahwa komunitas ESLint masih jauh lebih besar daripada komunitas TSLint. Selain itu, saya secara bertahap menyadari bahwa sistem kontrol tipe yang bagus membuat plugin linting tidak berguna. Sementara itu, saya menggunakan TypeScript ESLint, dan apa yang saya dapatkan terlihat cukup bagus.
Ini video saya tentang topik ini.
Dan omong-omong, saya merasa bahwa tim TypeScript condong ke ESLint, jadi saya kira saya membuat pilihan yang tepat.
▍ Mengapa kamu tidak memilih Alasan?
Dalam korespondensi di bawah tweet
ini , saya menjawab tawaran untuk mencoba TypeScript, mengatakan bahwa akan lebih baik untuk beralih dari Flow ke ReasonML. Bahkan, saya sering berbicara tentang beralih ke
Alasan sebelum beralih ke TypeScript. Salah satu alasan utama untuk pernyataan seperti itu adalah keinginan saya untuk melestarikan alat yang biasa, yang sudah saya bicarakan. Tetapi, karena saya tidak harus melepaskan apa pun, TypeScript ternyata lebih menarik bagi saya. Saya masih sangat menyukai Alasan, tetapi beralih ke Alasan akan berarti perubahan besar bagi banyak karyawan PayPal. Dan meskipun saya pikir mereka bisa mengatasinya, saya percaya bahwa mereka akan lebih nyaman menggunakan TypeScript daripada mencoba belajar bahasa baru.
Mungkin jika saya memilih Alasan, PR saya tidak akan pernah berakhir di repositori
sample-app . Adalah satu hal untuk mendorong kolega untuk menggunakan, pada dasarnya, apa yang bisa disebut "mengetikkan JavaScript" (terutama jika mereka tidak memerlukan dukungan untuk konfigurasi tertentu), dan percakapan yang sama sekali berbeda akan terjadi jika Anda mencoba mendorong kolega untuk menggunakan bahasa yang sama sekali berbeda dan ekosistem yang sama sekali berbeda (dan tidak masalah seberapa baik bahasa ini berinteraksi dengan JS dan npm).
Ringkasan
Sekarang, saya ingin
mengucapkan terima kasih kepada semua pengguna Twitter yang memengaruhi visi saya tentang TypeScript. Seperti yang saya katakan, fakta bahwa perpustakaan
paypal-scripts masuk ke repositori
sample-app di PayPal mungkin adalah pencapaian utama karier saya. Dan saya percaya bahwa fakta bahwa sekarang templat dari semua aplikasi baru di perusahaan dilengkapi dengan dukungan TypeScript secara default adalah nilai tambah yang besar untuk semua karyawan PayPal. Saya sangat senang bahwa saya memilih TypeScript.
Pembaca yang budiman! Apakah Anda pikir mereka yang menggunakan Flow harus melihat ke arah TypeScript?
