Less.js: ES6 & rollup

Tidak. Aku sudah berpikir sepanjang baris yang sama untuk sementara waktu. Bagaimana dengan menggunakan TypeScript? Mungkin membuat pengembangan/kontribusi lebih mudah untuk memiliki petunjuk kode/penautan objek nyata. Meskipun saya tidak tahu apakah ini akan menjadi beban / penghalang pengetahuan.

Saya juga memikirkan hal yang sama bahwa kita harus mempertimbangkan untuk menggunakan koleksi es6 untuk parsing/AST dan kemudian menggunakan polyfill untuk es5 build seperti https://github.com/Benvie/harmony-collections. Di lingkungan es6 (yang sekarang menjadi Node.js, seperti juga browser terbaru) yang secara teoritis akan mempercepat penguraian/evaluasi karena pengurangan overhead memori dan konstruksi AST yang lebih cepat.

Bagaimana dengan menggunakan TypeScript? Mungkin membuat pengembangan/kontribusi lebih mudah untuk memiliki petunjuk kode/penautan objek nyata. Meskipun saya tidak tahu apakah ini akan menjadi beban / penghalang pengetahuan.

Kami dapat mempertimbangkan bahwa setelah ES6 - es6 tidak menghalangi TypeScript karena TypeScript adalah transpiler es6 juga.. itu akan menjadi langkah tambahan setelah ini.

Saya pribadi tidak akan merekomendasikan TypeScript kecuali akan ada pekerjaan ekstra yang signifikan atau refactoring dalam waktu yang lebih sedikit. naskah IMO

• + membuat pengembangan untuk orang baru yang mengetahui TypeScript lebih mudah
• + meningkatkan pemeliharaan
• 
  
  • mengharuskan orang mengetahui atau mempelajari skrip dalam jumlah minimal
  
  
• 
  
  • membutuhkan waktu lebih lama untuk menulis kode sehingga diketik
  
  

Saya juga memikirkan hal yang sama bahwa kita harus mempertimbangkan untuk menggunakan koleksi es6 untuk parsing/AST dan kemudian menggunakan polyfill untuk es5 build seperti https://github.com/Benvie/harmony-collections. Di lingkungan es6 (yang sekarang menjadi Node.js, seperti juga browser terbaru) yang secara teoritis akan mempercepat penguraian/evaluasi karena pengurangan overhead memori dan konstruksi AST yang lebih cepat.

Saya tidak akan menggunakan polyfill itu, proyeknya terlihat mati (mungkin juga karena nama harmoni sudah mati).

Sayangnya saya juga tidak akan yakin bahwa padanan asli ES6 lebih cepat - https://jsperf.com/property-access-object-array-map-weakmap/6. Sedih bagaimana misalnya polyfill Janji lebih cepat daripada implementasi asli :(

:+1:

Semua poin bagus. Standarisasi pada ES6 / Babel sering kali membuat hal-hal tidak hanya lebih mudah untuk ditulis, tetapi juga dibaca, terutama saat melakukan pewarisan prototipikal.

Sejauh tes jsperf itu, itu bukan contoh yang adil. Saya berharap Weakmap bekerja lebih lambat untuk tes khusus itu. Secara teori, mungkin lebih baik bagi Less dalam membuat sekumpulan bentuk dan tipe objek yang berbeda dan kemudian mengevaluasinya. Tidak yakin. Saya menemukan beberapa perpustakaan bagus yang akhirnya ingin saya uji (dan mudah-mudahan menambahkan) di mana kita dapat menghubungkan ke fungsi individu untuk melakukan pembandingan granular, tanpa harus meletakkan "kait pembandingan" ke dalam lib. Saya berharap untuk mengatur sesuatu (ketika saya punya waktu, siapa yang tahu kapan itu akan terjadi) sehingga Anda dapat melakukan semacam tes jsperf pada fungsi dalam Less.js, tetapi dengan pengembangan lokal/cabang berubah menjadi Less vs. rilis saat ini, dan menggunakan beberapa jenis file uji .less. Seperti yang telah saya sebutkan sebelumnya, kita tidak perlu menebak mana yang lebih cepat untuk kasus penggunaan khusus kita. Kami secara teoritis dapat memasukkan WeakMap di beberapa tingkat fungsi vs. objek mentah, menjalankan tolok ukur di lokasi itu, dan memutuskan berdasarkan hasil.

@lukeapage menulis:
naskah IMO

• + membuat pengembangan untuk orang baru yang mengetahui TypeScript lebih mudah
• + meningkatkan pemeliharaan
• 
  
  • mengharuskan orang mengetahui atau mempelajari skrip dalam jumlah minimal
  
  
• 
  
  • membutuhkan waktu lebih lama untuk menulis kode sehingga diketik
  
  

Dan satu manfaat yang tidak disebutkan, sangat signifikan yang Anda lewatkan:
Mode diketik TypeScript memaksa Anda untuk menggunakan tipe variabel stabil, yang memberlakukan bentuk tipe stabil, yang meningkatkan kemampuan kompiler untuk secara statis _dan_ menganalisis kode Anda secara statis, yang menghasilkan kode yang dioptimalkan _jauh lebih baik_ dan menghentikan (atau setidaknya secara dramatis mengurangi) backout dari kode yang dioptimalkan kembali ke kode yang ditafsirkan lambat.

Pindah ke TypeScript mungkin akan berkontribusi lebih dari pindah ke ES6, imho.

Dengan mode mengetik yang Anda maksud adalah melarang Any?

Saya mencobanya pada proyek kecil dan saya memiliki anotasi di mana-mana .. itu berakhir
dengan banyak kode karena transpiler tidak terlalu pintar.

tentang berapa banyak variabel yang memiliki tipe variabel bermutasi, saya tidak yakin. jadi..
tidak yakin manfaat kinerja akan terlihat.

@rjgotten Saya belum pernah menggunakan TypeScript tetapi itu adalah poin bagus. Jika Anda menggunakan lingkungan intellisense/pelengkapan otomatis untuk TypeScript, itu mungkin benar-benar membantu kontributor baru karena itu akan melengkapi jenis/bentuk objek saat Anda membuat perubahan. Dirancang dengan benar, ini dapat berfungsi sebagai semacam alat dokumentasi diri / pengenalan / pencegahan kesalahan kepada seseorang yang berkontribusi pada perubahan kode. Tapi kuncinya mungkin ada di desain TypeScript.

Secara keseluruhan, apakah akan ada manfaat kinerja? Itu lebih sulit untuk ditentukan. Itu lebih artis daripada kanvas.

Meskipun saya bertujuan untuk menggunakan TypeScript untuk proyek saya sendiri, saya mungkin sedikit lebih setuju dengan @lukeapage , terutama karena, kecuali jika salah satu dari kita di sini adalah ahli TypeScript, saya tidak yakin kita bisa membuat penggunaan yang efektif dari itu awalnya.

Juga, pindah ke ES6 tidak mencegah penggunaan TypeScript di masa mendatang. Tujuan Microsoft / Google adalah menjadikan TypeScript 2.0 sebagai superset ES6, sehingga kami selalu dapat memulai dengan ES6 / Babel, dan kemudian menambahkan jenis yang tepat dan beralih ke transpiler TypeScript. Kecurigaan saya adalah bahwa TypeScript akan "memenangkan" bahasa yang ditranskripsikan, hanya karena manfaat waktu kompilasi/pelengkapan otomatis jauh lebih besar daripada JavaScript yang tidak diketik. Jadi... Saya rasa itu berarti saya pikir menggunakan TypeScript mungkin tidak bisa dihindari, tapi itu tidak berarti kita harus langsung menggunakannya.

Saya ingin membahas pendekatan arsitektur yang berbeda untuk Less di beberapa titik, tetapi itu lebih merupakan diskusi yang bersinggungan dengan ini.

Dengan mode mengetik yang Anda maksud adalah melarang Any?

Tidak. Hanya menggunakan variabel yang diketik secara umum. Anda _can_ melarang penggunaan Any secara umum, tapi itu (setidaknya praktis) ide yang buruk karena cenderung menyebabkan banyak kode mengasapi hanya untuk memenuhi sistem pengetikan.

Namun, penggunaan parameter yang diketik pada suatu fungsi berarti bahwa pemanggil (setidaknya pemanggil yang ditulis dalam TypeScript) _harus_ menghormati tipe yang diberikan. Itu berarti fungsi yang diketik dapat digunakan untuk melindungi stabilitas tipe pada cara kerja bagian dalam kompiler Less jika sesuai dan menjamin bahwa fungsi yang sangat penting akan dioptimalkan dengan baik. (Jangan lupa; Mesin JS umumnya mengoptimalkan pada tingkat fungsi ...)

pekerjaan dimulai - https://github.com/less/less.js/tree/rollup

Pekerjaan yang cukup keren. Germaine ke diskusi, saya melihat kode dan dengan cepat menemukan:

if (typeof index === 'number') {   

AFAIK jenis pemeriksaan kewarasan itu tidak akan pernah diperlukan dalam TypeScript. Jika tipe indeks diubah saat run-time menjadi string setiap kali melakukan perbandingan string untuk memeriksa tipe nilainya, hal-hal seperti itu dapat bertambah. Di TypeScript, jika ada panggilan ke fungsi yang melewati indeks, tetapi tipe itu terkadang bukan angka, dan hanya mengindeks _accepted_ angka, maka fungsi tersebut akan gagal pada waktu kompilasi karena tipe yang tidak cocok, daripada membutuhkan untuk diuji pada saat run-time, ketika cek tersebut lebih mahal.

Di sisi lain, bisa jadi ini adalah contoh yang terisolasi dan langka; itu hanya sesuatu yang saya temukan yang tampaknya relevan.

Saya pikir keuntungan terbesar dari tipe eksplisit adalah memungkinkan perkakas yang lebih kuat. Menemukan semua (dan hanya) tempat yang memanggil fungsi atau menimpanya hanya dengan pintasan keyboard. Mencari tahu fungsi mana dari objek yang Anda miliki tidak ada gunanya dan pemfaktoran ulang lebih aman karena kompiler menghasilkan lebih banyak kesalahan. Itu juga lebih mudah untuk mempelajari basis kode baru - mendapatkan gambaran besar, mencari tahu bagian mana dari kode yang bergantung atau mengikuti aliran kode tanpa menjalankannya lebih sulit di javascript daripada di java (misalnya), karena editor yang diketik lebih kuat.

Saya belum menggunakan TypeScript, jadi saya tidak tahu apakah alat cukup matang untuk membuatnya layak. Keuntungan javascript adalah semua orang mengetahuinya, TypeScript kurang dikenal.

Secara keseluruhan, saya pikir pindah ke TypeScript akan masuk akal jika kami merencanakan semacam refactoring yang lebih besar atau fitur baru yang besar, tetapi mungkin terlalu banyak pekerjaan sementara kami hanya memperbaiki bug kecil.

Saya pikir pindah ke TypeScript akan masuk akal jika kami merencanakan semacam refactoring yang lebih besar atau fitur baru yang besar, tetapi mungkin terlalu banyak pekerjaan sementara kami hanya memperbaiki bug kecil.

Ini mungkin masalahnya, dan sungguh, untuk menjadi pragmatis, @lukeapage telah mengambil pekerjaan jadi saya cenderung mengatakan dia harus membuat panggilan terakhir saat ini. :-)

Hei, tentang ini: apakah ada yang harus kita lakukan untuk memberi tahu orang-orang bahwa basis kode berubah? Saya berasumsi bahwa jika tidak, Anda akan mengalami konflik gabungan.

tidak, tidak boleh terlalu banyak konflik. langkah pertama hanyalah modul es6 - bukan
memindahkan file apa saja, maka kita dapat menambahkan babel atau TypeScript secara transparan.

Hai guys, gimana kabarnya sekarang?

Saya bisa mengerjakan ini. @matthew-dean Maukah Anda menerima permintaan tarik?

@alexlur Pasti ! Satu-satunya kekhawatiran saya adalah refactoring untuk cabang 3.x dan tidak mendapatkan konflik gabungan. Jadi lebih baik bercabang/bercabang dari sana. Juga, sejak masalah ini ditulis, sekarang ada konvensi yang sudah mapan sekarang menggunakan src/ dan dist/ . Namun, lib/ terkadang digunakan sebagai src/ , jadi mungkin tidak perlu mengganti nama.

Juga akan ada sedikit penulisan ulang Gruntfile sehingga pengujian menggunakan build dan bukan lib/ . (Apa yang dilakukan pengujian browser adalah melakukan build di test/ dan bukan dist/ . Folder dist/ adalah tugas Grunt khusus untuk rilis baru. Saat pengujian, folder harus dibuat untuk test/ ) Setelah melakukan itu, selama tes lulus, Anda harus baik-baik saja.

@matthew-dean Halo. Saya sudah selesai dengan refactoring tetapi saya tidak tahu cara mengkonfigurasi Gruntfile untuk menjalankan tes pada file yang baru dibangun.

Mungkin yang bisa saya lakukan adalah menggabungkan perubahan Anda menjadi cabang terpisah dan melihat tentang mengintegrasikan tes. Saya hanya dengan cepat melihat-lihat perubahan Anda. Koreksi saya jika saya salah, tetapi apakah at-rule salah node assignment ? Atau apakah Github hanya mengacaukan cara menampilkannya?

Tangkapan bagus, saya menggunakan file yang salah.

Apakah ada versi minimum browser/Node.js yang harus didukung less.js? Node.js memiliki dukungan yang cukup baik untuk Promise (sejak 0.12), sedangkan dalam penggunaan browser umumnya untuk developer yang sudah menjalankan versi browser terbaru pula.

Sunting:

Less.js mendukung semua browser modern (versi terbaru Chrome, Firefox, Safari, IE11+, dan Edge)

Hanya Internet Explorer 11 yang tidak memiliki Promise bawaan.

@alexlur
Untuk versi Less dalam browser, saya sarankan membuat properti less.Promise , dan menyetelnya ke window.Promise secara default. Dan kemudian memiliki Less mengkonsumsi kelas Promise melalui less.Promise .

Dengan cara ini, pengguna browser modern serta pengguna yang memiliki Promise secara global polifill sebelum Less dimuat, semuanya akan berfungsi secara ajaib. Dan pengguna yang tidak ingin -- atau karena alasan apa pun tidak diizinkan -- polyfill secara global dapat membuat semuanya bekerja dengan satu langkah tambahan kecil. Mereka hanya perlu menetapkan implementasi Promise pilihan mereka secara manual ke less.Promise sebelum benar-benar menggunakan Less.

@rjgotten @alexlur Less.js sudah menyiapkan Promise polyfills. Tidak perlu melakukan pekerjaan tambahan di sana. Sebagian besar kode menggunakan pola ini:

https://github.com/less/less.js/blob/55380d49e96a6ed561cac4d13a774830aa3c17a3/lib/less/import-manager.js#L5

Di sisi Node, ada masalah ini yang masih terbuka: https://github.com/less/less.js/issues/3121

Namun, tanpa umpan balik, dan dengan jumlah kontributor yang cukup moderat, saya cenderung hanya mengatakan Node 4+ adalah cara yang harus dilakukan untuk saat ini. Kami harus memperbarui dokumen / tes untuk mencerminkan hal itu.

@matthew-dean Itu harus siap untuk digabungkan ke cabang yang terpisah .

@alexlur Terima kasih! Saya akan mencoba untuk melihat segera. Mungkin akan minggu depan (kecuali orang lain memiliki waktu luang untuk memeriksanya).

Masalah ini secara otomatis ditandai sebagai basi karena tidak ada aktivitas terbaru. Ini akan ditutup jika tidak ada aktivitas lebih lanjut yang terjadi. Terima kasih atas kontribusi Anda.

Saya membuat garpu yang di-refactored ke TypeScript.

Saya membuat garpu refactored ke TypeScript.

@glixlur wow, dan semua tes lulus? Dan membangun less.js yang identik di dist/ ?

@matthew-dean Saya masih mengerjakannya, tetapi build saya untuk browser tidak mengalami masalah sejauh ini sebagai driver harian. Secara teknis menggunakan rollup memberi garpu saya keunggulan dalam kinerja tetapi saya tidak memiliki data untuk mencadangkannya.

@less/core Ini harus diselidiki untuk melihat apakah kami dapat mengotomatiskan ini untuk konversi satu kali - https://github.com/lebab/lebab

@matthew-dean Saya akan mengirimi Anda permintaan tarik setelah saya selesai.

@glixlur Oh! Oke, di PR Anda sebelumnya , Anda mengatakan Anda tidak punya waktu untuk ini. Jika Anda masih mengerjakan ini, 👍

@matthew-dean Saya akan membatasi diri untuk hanya mengonversi ke ES6 dan meninggalkan bagian TypeScript nanti.

@glixlur Saya pikir ES6 mungkin adalah langkah pertama yang paling "ramah komunitas" untuk bergerak maju, jadi itu sempurna. Saya tidak yakin semua orang setuju dengan TypeScript, tapi pasti aliran ES6 akan bagus.

@matthew-dean Saya menganggap platform yang didukung terendah adalah Node 6 dan IE11?

@glixlur Appveyor saat ini disiapkan untuk menguji Node 4. Apakah itu akan membuat segalanya lebih sulit? Idealnya, Babel akan mengubah folder src/ menjadi folder (diganti) lib/ (dan dist/ untuk browser) untuk didistribusikan ke Node/browser. Jadi saya akan menganggap Babel melakukan sebagian besar pekerjaan transpiling ke ES5.

Selesai , tetapi perlu membuat tes berfungsi. PhantomJS sudah usang dan tidak memiliki dukungan untuk apa pun setelah ES5.

@glixlur Bagus! Re: PhantomJS, itu benar-benar perlu diganti dengan sesuatu seperti Chromy. Lihat: https://github.com/less/less.js/issues/3240

@glixlur Juga, ini terkait dengan Chromy / Chrome tanpa kepala: https://github.com/less/less.js/issues/3262

@glixlur Mengenai PhantomJS - tes tersebut berjalan terhadap versi browser yang dibundel, yang mungkin Anda ubah ke ES5, benar? Mengapa PhantomJS tidak bekerja dengan bundel keluaran ES5?

@matthew-dean Ya, tetapi ada bug di mana Symbol digunakan saat menjalankan PhantomJS dengan file yang di-transpilasikan Babel.

@glixlur Anda memerlukan babel-polyfill dalam hasil transpilasi. Itu indikator yang baik itu belum transpiling dengan benar. Lihat masalah seperti: https://github.com/babel/babel-preset-env/issues/203

@glixlur https://babeljs.io/docs/en/babel-polyfill/

@matthew-dean babel-polyfill menambahkan 87.3KB yang diperkecil ke file output. Anda mungkin tidak menginginkan itu.

@glixlur
Ada alasan lain Anda tidak ingin babel-polyfill . Yaitu fakta bahwa itu mempengaruhi namespace global dengan menerbitkan polyfill pada window dan memodifikasi prototipe tipe asli seperti Array .

Lihat ke babel-runtime dan paket babel-plugin-transform-runtime sebagai gantinya.

Juga, iirc tim Babel sedang bekerja untuk membatasi polyfill yang dibundel oleh transform-runtime sepanjang baris yang sama dengan transformasi bahasa batas preset babel-env . Tetapi pekerjaan mereka belum selesai dan tersedia secara umum. Akan berakhir dengan Babel 7, yang masih dalam versi beta, jadi tidak langsung berguna. Tapi pasti diinginkan untuk masa depan.

@glixlur @rjgotten Ah. Saya seharusnya mengklarifikasi bahwa saya tidak tahu persis solusi mana yang harus digunakan re: Babel. Hanya saja itu karena Symbol tidak terdefinisi karena bukan polyfill (ponyfilled?), yang juga akan ada di IE11. Jadi mungkin itu bukan polyfill, tapi saya percaya dengan pengaturan Babel yang tepat, itu akan memberi Anda definisi Symbol yang dicakup. Jadi mungkin itu versi browser min yang menjadi masalah?

dengan pengaturan Babel yang tepat, itu akan memberi Anda definisi Symbol yang tercakup

Ini memang akan.
Pengaturan tersebut sama dengan menggunakan plugin transform-runtime dan kemampuannya untuk menyuntikkan alias untuk bawaan yang lebih baru seperti Symbol , alih-alih mengandalkan babel-polyfill .

Haruskah phantomjs ditinggalkan?

Mengingat itu sudah mati?
Mungkin iya.

@glixlur Lihat: https://github.com/less/less.js/issues/3240

Konversi selesai dan digabungkan! Lihat: https://github.com/less/less-meta/issues/32

Yah, minggu ini saya mengetahui bahwa Class dalam JavaScript BUKAN sekadar gula sintaksis untuk prototipe fungsi, yang menyebabkan masalah ini: https://github.com/less/less.js/issues/3414

Ironisnya, saya menemukan hal yang sama dengan sedikit kode lain yang tidak terkait dengan Less, kira-kira 2 minggu yang lalu dan saya ingat dengan jelas pemikiran yang mengenai saya:

astaga, saya ingin tahu apakah konversi ES6 untuk Less akan menyebabkan masalah seperti ini.

Nah: pertanyaan dijawab, saya kira?

Saya _so_ tidak iri dengan badai pengguna yang mencurahkan ketidakpuasan mereka atas pekerjaan Anda, @matthew-dean. Anda memiliki simpati saya harus menangani situasi itu. :senyum:
Untungnya, tampaknya tidak ada yang menjadi apokaliptik dan ditangani dengan tertib.

@rjgotten lol Maksudku, bagaimana Anda bisa mengantisipasi hal seperti itu? Hal teraman adalah tidak mengonversi sama sekali, atau tidak pernah menggunakan kelas, tetapi itu membuat basis kode kurang bertele-tele (well, atau berpotensi akan, ada banyak peluang untuk pembersihan lebih lanjut). Secara teknis, integrasi (historis) less-loader dengan Less adalah penyalahgunaan API (menggunakan penggunaan API yang tidak didokumentasikan/tidak didukung), jadi itu adalah kesalahan mereka, tetapi saya bersimpati dengan orang-orang yang frustrasi karena rilis poin non-utama yang menyebabkan kegagalan build.

Seperti, jika seseorang meretas prototipe di perpustakaan Anda, bagaimana Anda membuat kode untuk itu??

🤷♂.

@rjgotten

Secara teknis, saya merilis dua versi beta setelah konversi, TETAPI... tidak ada yang memiliki Lebih sedikit beta di saluran mereka. Jadi tidak ada cara untuk menguji 800.000 repo yang terintegrasi dengan Less dan menjalankan pengujian mereka. Dengan dependensi NPM, Anda benar-benar harus meletakkannya di sana dan melihat apa yang rusak.

Satu hal yang bisa kita lakukan di masa depan adalah menambahkan beberapa tanggungan yang lebih besar ke tes, jika kita dapat mengetahui apa itu?

Hal lain yang bisa saya lakukan adalah merilisnya sebagai versi utama, tapi.... secara teknis TIDAK ada perubahan yang melanggar (disengaja), yaitu fitur yang didukung identik, dan itu mencakup beberapa perbaikan bug, jadi.. .. Entahlah, ini yang rumit.

Ya. Itu rumit.

Saya kira Anda bisa mencoba untuk hanya menempatkan sesuatu pada tag .next atau sesuatu dan membuat orang sadar untuk menguji pipa build mereka dengannya. Tetapi pengalaman masa lalu menunjukkan bahwa hal semacam itu umumnya tidak terdengar.

Either way, versi utama atau tidak, Anda mungkin akan dipaksa untuk hanya "coba" dan lihat apa yang rusak.

Jangan salah paham: refactor adalah hal yang sangat bagus. Ke depan, umumnya harus mengambil bagian yang baik dari beban pemeliharaan.

Seperti, jika seseorang meretas prototipe di perpustakaan Anda, bagaimana Anda membuat kode untuk itu??

Anda benar-benar tidak.

Ini seperti orang-orang yang mengeluh bahwa IL runtime-emit mereka yang diatur dengan hati-hati untuk mengakses anggota pribadi di C# istirahat di rilis kecil. Jika Anda mencampuri urusan internal, Anda harus tahu apa yang Anda beli. :senyum:

@rjgotten Berbicara tentang refactoring...

..... Salah satu hal yang saya temukan dari waktu ke waktu di basis kode Less adalah bahwa ada sejumlah tempat di mana ada sedikit/mutasi halus pada objek di AST. Properti baru di sini / metode tambahan pada instance di sana, dan saya akan sepenuhnya mengakui telah melakukan ini kadang-kadang dengan fitur yang saya gabungkan, karena dalam JavaScript, Anda dapat mengubah apa pun yang Anda inginkan, kapan pun Anda mau, apakah Anda didokumentasikan/didefinisikan properti itu atau tidak.

Ada beberapa diskusi tentang apakah TypeScript vs. JS modern saja yang akan menjadi jawabannya. Saya telah menyadari bahwa tidak memiliki tipe atau antarmuka objek yang jelas membuat basis kode Less terkadang sangat sulit untuk dipikirkan dengan cara yang tidak dapat diselesaikan oleh dokumentasi atau bahkan JSDocs.

Saya mengatur pipa baru untuk memungkinkan linting TypeScript _if_ Anda memiliki tipe yang tepat di JSDoc, tetapi menggunakan JSDoc untuk mengetik waaaaaaaay lebih bertele-tele / berisik secara visual daripada TypeScript, dan ada beberapa fitur pengetikan yang TS tidak mendukung hanya melalui anotasi JSDoc . Tidak ada kombinasi alat JSDoc / ESLint yang dapat menyelesaikan beberapa hal ini yang diberikan TS kepada Anda secara gratis.

Jadi, saya kira semua yang saya katakan adalah bahwa setelah menggunakan TypeScript secara signifikan pada tahun lalu, dan setelah menghabiskan bertahun-tahun di basis kode Less, saya akan mengatakan 95% dari kurva kebingungan/frustrasi/belajar mencari tahu bagaimana Less bekerja telah dihindari jika objek memiliki tipe waktu kompilasi yang diberlakukan. Saya sering menghabiskan banyak waktu di debugger hanya mengatur breakpoint dan mencari tahu apa properti objek _sebenarnya_, alih-alih bagaimana mendefinisikannya dalam file.

Misalnya, ada sejumlah fitur yang Less miliki, selama evaluasi, bergantung pada properti Ruleset node paths . Dari konstruktor ini , dapatkah Anda memberi tahu saya apa properti paths itu, dan seperti apa bentuknya? (Petunjuk: Anda tidak bisa, karena itu tidak ada.)

Di TypeScript (dengan pengaturan tsconfig umum), ini tidak akan diizinkan. Itu bahkan tidak akan dikompilasi. Anda akan dipaksa untuk menentukan bentuk paths , dan persis apa yang akan ada di dalamnya, yang kemudian akan memberikan dokumentasi yang jelas dan spesifik (dan petunjuk kode) kepada seseorang yang menjelajahi basis kode.

Jadi, saya kira pada titik ini, saya beralih dari berpikir, "TypeScript adalah sesuatu yang harus dipertimbangkan" menjadi merasa seperti, "Jika proyek publik Anda tidak ada di TypeScript, Anda memiliki hutang teknis yang besar." Saya tidak akan pernah memulai repo open source tanpa itu, karena secara inheren membantu memecahkan kemampuan konsumsi dan pemeliharaan. Anda masih memerlukan dokumentasi yang jelas, tetapi setidaknya ini memberlakukan pengkodean yang sangat jelas dan kohesif.

Itu hanya saya yang memikirkan ke mana harus pergi dari sini, dan cara untuk mencegah titik nyeri di masa depan.

_( Tambahan : jika tidak jelas, saya 100% tidak merusak karya historis siapa pun di basis kode Lebih Sedikit. Ada banyak hal yang telah saya usulkan, diterima, dan digabungkan ke dalam basis kode yang sekarang saya ' seperti, "Oof, saya berharap saya tidak melakukan itu," atau berharap saya melakukannya secara berbeda. Dan saya tentu saja menambahkan hal-hal yang saya sadari sekarang mungkin berdampak negatif pada pemeliharaan. Semua orang telah melakukan yang terbaik.)_

@matthew-dean
Saya mengatur pipa baru untuk memungkinkan linting TypeScript jika Anda memiliki tipe yang tepat di JSDoc, tetapi menggunakan JSDoc untuk mengetik adalah waaaaaaaay lebih bertele-tele / berisik secara visual daripada TypeScript, dan ada beberapa fitur pengetikan yang tidak didukung oleh TS hanya melalui anotasi JSDoc . Tidak ada kombinasi alat JSDoc / ESLint yang dapat menyelesaikan beberapa hal ini yang diberikan TS kepada Anda secara gratis.

Sebenarnya; Saya mengalami masalah dengan dukungan JSDoc yang biasa-biasa saja untuk inferensi tipe sendiri.
Untungnya Anda dapat menggunakan file deklarasi .d.ts di sebelah file sumber .js , tanpa perlu menggunakan TypeScript sepenuhnya dan memerlukan kompiler.

Dulu jauh lebih sulit untuk bekerja dengan file deklarasi, tetapi versi modern dari kompiler TypeScript akan secara otomatis mengaitkan file .d.ts berdampingan dengan file .js selama keduanya diberi nama sama.

Itu mungkin yang Anda cari.

@rjgotten Bisakah Anda menjelaskan lebih banyak (atau tautan jika Anda tahu sumber yang bagus), tentang bagaimana ini bisa bekerja dengan baik dengan basis kode Less? Seperti, bagaimana Anda melakukan ini pada file demi file level? Apakah ada file .d.ts per modul .js ? Atau apakah Anda mengelompokkannya?

Apa keuntungan memiliki file .d.ts vs hanya menggunakan TypeScript di sumber? Mengapa menghabiskan waktu membuat file .d.ts alih-alih hanya mendefinisikan jenis-jenis itu dalam file?

@rjgotten Saya berbicara dengan pengembang Chevrotain hari ini, dan dia mengatakan apa yang dia lakukan adalah mengembangkan di TS _BUT_ dia benar-benar mengelola file api.d.ts sebagai masalah terpisah. Dengan begitu, setiap perubahan tipe pada file sumber (seperti simpul pohon) tidak secara transparan/tidak terlihat mengubah API publik tanpa perubahan eksplisit pada file tipe api.

Kemudian dia menggunakan tes dengan pernyataan bahwa tipe internal dan tipe API publik cocok -> https://github.com/SAP/chevrotain/blob/master/packages/chevrotain/test_integration/definitions/api_type_checking.ts#L1 - L2

Cara Chevrotain adalah cara yang baik untuk menegakkan API publik Anda agar tidak berubah secara tidak sengaja. Sangat kuat, jika Anda merasa membutuhkan tingkat perlindungan itu. Tetapi juga menimbulkan beberapa overhead.

Mengenai penggunaan file deklarasi .d.ts untuk menahan pengetikan .js :
Ini sebenarnya keduanya.

Jika mereka berjalan berdampingan, maka setiap IDE yang didukung oleh kompiler TypeScript untuk saran otomatis, linting, dll. akan secara otomatis mengambil pengetikan. Afaik _also_ jika skrip dengan pengetikan berdampingan diimpor dari node_modules , yang cukup bagus.

Anda juga dapat memasukkan pengetikan ke dalam satu (set) file .d.ts seperti api.d.ts dan kemudian menggunakan JSDoc untuk mengimpor tipe yang dideklarasikan secara eksplisit. Dukungan JSDoc di TypeScript memiliki rasa khusus @typedef untuk itu dengan sintaks impor. Misalnya

/**
 * <strong i="17">@typedef</strong> {import("../api.d.ts").MyType } MyType
 */

Menggunakan satu file pengetikan yang dibundel adalah ide yang baik jika Anda harus mengambil paket Anda melalui langkah transpiling sebelum distribusi. Dalam kasus seperti itu, apa yang sebenarnya akan dilakukan pengguna require() atau import {} tidak akan menjadi file sumber asli lagi. Yaitu mereka tidak akan mendapat manfaat dari pengetikan berdampingan.