<p>Rencana Iterasi TypeScript 4.0</p>

Apakah Anda mempertimbangkan untuk memasukkan https://github.com/microsoft/TypeScript/pull/29818 di 4.0 mungkin di belakang bendera eksperimental?

Itu menjadi rumit dengan perubahan definisi fungsi pabrik itu sendiri.

Mungkin menarik untuk memperkenalkan definisi tipe virtual pabrik _separate_; katakanlah, JSX.Factory , atau React.JSX.Factory , yang kemudian dapat digunakan TypeScript untuk inferensi. Saya tidak yakin hanya menerjemahkan tata bahasa JSX ke panggilan fungsi sudah cukup atau efisien tetapi, karena ini adalah tipe virtual, itu tidak harus sesuai dengan entitas JavaScript konkret apa pun. Risikonya, tentu saja, masuk ke situasi yang sama seperti yang kita alami sekarang, dengan sekelompok tipe virtual yang akhirnya membatasi keamanan tipe, tidak hanya anak-anak, tetapi beberapa fitur yang diperkenalkan setelah React 15.

Apakah Anda mempertimbangkan untuk juga menyertakan https://github.com/microsoft/TypeScript/pull/24738 di 4.0 juga?

Saya agak sedih melihat tidak disebutkannya #33038 [👍 140 dan PR aktual oleh @weswigham Anda sendiri] atau #202 [👍 390] sementara tiket seperti #15230 [👍 27] dianggap "permintaan tinggi". Saya menyadari Anda tidak dapat benar-benar membandingkan atau memprioritaskan berdasarkan "suka" tetapi akan lebih bagus jika ada beberapa pembaruan peta jalan tentang ini, terutama karena 4.0 sepertinya merupakan peluang bagus untuk memperkenalkan fitur seperti ini. 🙏

~Masalah 3,5 tahun menunggu umpan balik dengan hampir 200 komentar #13778 dengan pengetikan yang tidak akurat yang disediakan untuk hal-hal seperti perusakan susunan. Pwetty pwease bisakah kita menerapkan perbaikan 🙏

Saya menghargai orang-orang yang kadang-kadang meningkatkan masalah yang mereka yakini perlu diperhatikan pada peta jalan dan rencana iterasi, tetapi saya pikir saya perlu memperjelas di sini -bahwa bagian "selidiki perbaikan bug permintaan tinggi" ditentukan dengan melihat melalui masalah yang jelas-jelas menyebabkan banyak masalah. potongan kertas tetapi yang tampaknya masuk akal dalam ruang lingkup. Kami pasti masih memperhatikan masalah yang disebutkan, tetapi beberapa di antaranya tidak memiliki cakupan yang luas dan juga tidak memiliki hasil ideal yang jelas.

Contoh:

• Merek nominal akan bagus, tetapi apakah itu sesuai dengan arah bahasa masa depan seputar nominalitas? Saya bahkan memiliki kekhawatiran dengan tipe placeholder sebagai orang yang mengusulkannya.
• undefined pada tanda tangan indeks adalah contoh dari sesuatu yang menarik, tetapi kami tidak ingin menambahkan perilaku yang mempersulit 90% orang yang sudah beroperasi di bawah asumsi saat ini. Menemukan pendekatan yang menyusun dan memungkinkan pengguna untuk secara bertahap mengadopsi pemeriksaan tersebut bukanlah sesuatu yang jelas bagi kami. Bahkan jika secara teknis dimungkinkan dengan sekelompok tipe bersyarat dan pemeriksaan kompiler khusus, solusi tersebut cenderung sangat jelas meretas dan cepat rusak.

Merek nominal akan bagus, tetapi apakah itu sesuai dengan arah bahasa masa depan seputar nominalitas?

@DanielRosenwasser apa arah bahasa masa depan dalam visi Anda?

Saya kira saya akan memberikan beberapa konteks di mana pikiran saya dengan nominalitas. Ada banyak ide berbeda yang ada di benak orang ketika mereka bertanya tentang tipe nominal, termasuk

• Nominalitas berbasis deklarasi "Tradisional" (mis. apa yang Anda lihat di sebagian besar bahasa OO)
• Jenis buram (jenis yang isinya sama sekali tidak diketahui di luar)
• Alias ​​berbeda (anggota tunggal struct s di C/C++/C#, newtype di Haskell, kelas sebaris di Kotlin)
• Satuan ukuran (cara untuk mengkodekan analisis dimensi ke dalam bahasa)

Ada nuansa di antara beberapa di antaranya (misalnya deklarasi tipe placeholder - jenis varian dari tipe buram yang kembali ke tipe implementasi), dan kemudian ada arah berbeda yang memadukan masing-masing ini bersama-sama.

@RyanCavanaugh memiliki analogi yang bagus tentang ini di mana 3 anak meminta hewan peliharaan kepada orang tua mereka. Yang satu mau anjing, yang satu mau kucing, yang satu mau ikan. Mereka bertanya kepada orang tua mereka "kapan kita punya hewan peliharaan!?" Jelas mereka semua setuju bahwa mereka menginginkan hewan peliharaan, tetapi masing-masing menginginkan hewan peliharaan yang berbeda!

Apakah saya suka tipe bermerek? Saya bersedia! Jenis bermerek mencapai sesuatu seperti alias berbeda, dan sesuai dengan apa yang dicari sebagian besar pengguna. Tapi saya rasa itu bukan cara yang tepat untuk memikirkannya. Ada lebih banyak ruang desain yang harus disempurnakan dengan banyak pengorbanan yang diketahui, dan tidak ada yang memberi saya perasaan bahwa kita perlu mempercepat solusi secepatnya.

Saya ingin jika kita bisa mendapatkan https://github.com/microsoft/TSJS-lib-generator/pull/858 ke TypeScript 4.0 .

@DanielRosenwasser pertama-tama terima kasih atas tulisannya

Bisakah Anda menguraikan sedikit tentang kasus penggunaan apa yang sebenarnya ditangani oleh tipe nominal untuk TypeScript?

Pertama: jangan ragu untuk mengirim saya ke dinding raksasa teks atau repo dan saya akan membacanya :]

Maksud saya bukan tipe buram seperti tipe placeholder - maksud saya apa yang Anda sebut tipe nominal "Tradisional".

Saya selalu merasa tipe nominal bertentangan dengan JavaScript dan itulah mengapa upaya sebelumnya tidak berhasil dengan baik. Ada beberapa cara untuk membuatnya bekerja dengan cukup baik (protokol di Swift dan kelas tipe di haskell muncul dalam pikiran sebagai "Nominal tetapi dapat diperpanjang dari luar") dan saya yakin Anda terbiasa dengan sebagian besar cara "mapan" (Saya menganggap "satuan ukuran" adalah kedipan F#).

Saya telah menemukan banyak orang meminta jenis nominal (seperti dalam "tradisional") tetapi tidak banyak tulisan tentang _why_.

Seiring waktu, kami telah melihat semakin sedikit orang yang meminta tipe nominal "tradisional", mungkin karena secara kolektif komunitas telah membangun mode mental untuk tipe struktural. Ada beberapa tempat di mana tipe benar-benar bertindak secara nominal (ketika instanceof terlibat atau ketika ada privat). Beberapa di antaranya ditangkap dengan analisis aliran kontrol dan pemeriksaan kompatibilitas yang lebih baik, tetapi tidak sempurna.

Beberapa kasus penggunaan "tradisional" sama dengan jenis pembungkus nominal tanpa overhead (misalnya newtype ), dan sering kali tujuannya adalah untuk memastikan penanganan khusus untuk hal-hal seperti file jalur, string tidak tepercaya, dll.

Saya merasa TypeScript sudah cukup ekspresif. Apa yang saya pribadi ingin lihat adalah integrasi perkakas yang lebih baik.

• dukungan untuk ESM https://github.com/microsoft/TypeScript/pull/35148 https://github.com/microsoft/TypeScript/issues/16577
• plugin kompiler https://github.com/microsoft/TypeScript/issues/16607 https://github.com/microsoft/TypeScript/issues/38736
• benang pnp https://github.com/microsoft/TypeScript/issues/28289 https://github.com/microsoft/TypeScript/pull/35206

Karena di atas itu adalah umum untuk melihat solusi kikuk dan hacky. Sebagian besar proyek reaksi memiliki babel yang disertakan untuk react-hot-loader (plugin kompiler), beberapa sistem CSS juga memerlukan babel untuk transformasi waktu kompilasi. Menggunakan modul pnp, esm atau bahkan CSS memerlukan lebih banyak alat dan solusi untuk batasan tsc.

Hal ini juga membuat frustrasi bahwa untuk beberapa masalah ini masyarakat datang dengan solusi konkret dalam bentuk PR atau proposal tetapi ditolak atau terhenti selama bertahun-tahun. Sebagai praktisi, penggunaan TS semakin sulit dalam konteks ekosistem yang lebih luas.

Pokoknya saya hanya orang acak dari internet.

@DanielRosenwasser mungkin https://github.com/microsoft/TypeScript/pull/29374 bisa ditinjau tepat waktu untuk 4.0? Saya pikir ini mencakup banyak (sebagian besar?) dari this -sebelum- super kasus yang cenderung ditanyakan orang.

Harap pertimbangkan kembali termasuk dukungan untuk mereferensikan modul ES dengan jalur file termasuk ekstensi file. Ini akan memberikan dorongan besar untuk menyamakan bidang permainan kode multi-lingkungan.

https://github.com/microsoft/TypeScript/issues/16577

Terima kasih atas fokus Anda pada perkakas di sekitar TypeScript! Saya berharap Anda dapat mempertimbangkan untuk menyediakan integrasi yang lebih dekat dengan https://github.com/microsoft/tsdoc. Banyak bahasa modern lainnya seperti go and rust menyediakan alat dokumentasi langsung dari kotak dan mendorong pengembang untuk menulis komentar standar, tetapi TypeScript kurang dalam hal ini.

Akan sangat bagus jika #31445 dapat diambil, ini telah menjadi pemecah kesepakatan bagi kami dan saya percaya banyak orang (berdasarkan berapa banyak referensi yang dimiliki masalah itu)!

Bisakah https://github.com/microsoft/TypeScript/pull/38967 dimasukkan dalam TypeScript 4.0 , dan mungkin juga https://github.com/microsoft/TypeScript/pull/35608 .

Saya menemukan orang-orang meminta semuanya untuk dimasukkan dalam rilis 4.0

Terasa seperti TS kehilangan momentum? Penggabungan nol dan tugas hubungan arus pendek untuk rilis _major_, 4.0.0 berikutnya? Tidak ada tujuan besar dan ide ambisi lagi?

Untuk jurusan berikutnya, saya mengharapkan:

• Mengetik lebih tinggi
• Mengetik tergantung? Fungsi tingkat tipe? (Oke, yang ini bisa untuk 5.0.0)
• Pengetikan nominal
• Makro
• Dukungan untuk transformer di tsconfig.json
• Kompilasi ke WASM (dari beberapa subset bahasa)

@canonic-epicure Setuju, saat ini rasanya lebih seperti 3.10 untuk versi berikutnya

Terasa seperti TS kehilangan momentum? Penggabungan nol dan tugas hubungan arus pendek untuk rilis utama 4.0.0 berikutnya? Tidak ada tujuan besar dan ide ambisi lagi?

TypeScript tidak mengikuti semver. Tidak ada v0.10, v1.10, v2.10, atau v3.10. Jadi ini sebenarnya adalah tonggak yang normal. Agak aneh orang mengharapkan begitu banyak perubahan di 4.0 tetapi tidak mengatakan apa-apa di 3.9 atau rencana iterasi sebelumnya. 🙈.

Fungsi tingkat tipe

type X<T> = T dapat melakukannya pada tingkat tertentu. (tidak mendukung fungsi tingkat tinggi.)

Makro

IMO itu tidak memenuhi tujuan TypeScript.

Dukungan untuk transformer di tsconfig.json

Cobalah: https://github.com/cevek/ttypescript

Kompilasi ke WASM (dari beberapa subset bahasa)

Apakah Anda mencari https://www.assemblyscript.org/

Oke, jadi 4.0.0 hanyalah rilis kecil berikutnya, bagus untuk diketahui.

Mengenai "makro tidak memenuhi tujuan TS" dan "gunakan ttypescript untuk transformer" ( ts-patch bekerja lebih baik btw) - ini menyerupai jedi move - "ini bukan fitur yang Anda butuhkan". Tidak, makro dan trafo di luar kotak. Itu sudah diminta bertahun-tahun yang lalu.

Saya juga ingin marco di TypeScript tetapi ada banyak alasan yang menentang ini.

1. jika Marco dapat menghasilkan kode JavaScript yang berbeda, itu membuat sintaks level non-tipe baru, oleh karena itu ini merupakan ekstensi untuk spesifikasi ES. enum , import x = require(...) , module adalah pengecualian dari aturan ini tetapi mereka berasal dari waktu awal TypeScript.

2. jika Anda ingin menggunakan Marco lintas file yang berbeda untuk menghasilkan file JS yang berbeda, maka tidak mungkin untuk membuang semua jenis sintaks untuk mendapatkan file JavaScript.

3. Marcos dapat meningkatkan waktu analisis & kompilasi, dan kemungkinan akan disalahgunakan.

4. Jika Marco dapat memancarkan file JS yang berbeda berdasarkan jenis info, itu akan membuat Babel tidak mungkin untuk menangani sintaks ini. Jadi perilaku ini melanggar aturan isolatedModules (pengecualian: const enum dan module )

5. Jika Marco hanya dapat melakukan "tipe level Marco" dan dapat dihapus oleh Babel dengan aman, itu menjadi sangat tidak berguna tetapi masih berguna untuk tipe tingkat tinggi / terprogram. Oleh karena itu tidak melanggar tujuan apa pun, tetapi saya ragu apakah tim TypeScript akan tertarik dengan ide tersebut. (Saya telah membuat demo di https://github.com/Jack-Works/typescript-marco-demo/blob/master/marco-test.ts).

@Jack-Works Saya tidak mengerti poin Anda. Mungkin maksud Anda makro akan memperluas parser dan membuat sinatx baru?

Bagi saya, makro hanyalah fungsi AST -> AST, yang entah bagaimana menjalankan pemeriksa tipe sebelumnya, oleh karena itu dapat membuat node AST baru yang akan diperiksa secara teratur. Namun itu tidak membuat sintaks baru - inputnya adalah AST biasa, outputnya juga. Itu membuat node baru di AST.

Diskusi akan di luar topik untuk utas ini, mungkin akan dilanjutkan di saluran #compiler di discord?

Bisakah #38597 disertakan dalam TypeScript 4.0

@DanielRosenwasser

undefined pada tanda tangan indeks adalah contoh sesuatu yang menarik, tetapi kami tidak ingin menambahkan perilaku yang mempersulit 90% orang yang sudah beroperasi di bawah asumsi saat ini.

Hanya ingin tahu bagaimana Anda tahu itu 90% dari orang-orang?

@wongjiahau nomor itu dibuat santai demi penjelasan. Tidak yakin apakah itu poin spesifik yang Anda tanyakan.

Sebagai informasi, tim kami tidak akan bekerja pada 19 Juni, jadi kami akan sedikit mendorong jadwal. Beta sekarang dijadwalkan untuk dikirimkan pada Kamis depan, 25 Juni.

@DanielRosenwasser Saya mencoba menunjukkan bahwa Anda menggunakan beberapa angka arbitrer yang dibuat-buat untuk menyangkal pentingnya fitur (#13778) yang secara jelas selaras dengan tujuan pertama TypeScript, yaitu untuk mengidentifikasi konstruksi yang mungkin secara statis

Tolong jangan salah paham, saya menghargai kerja keras yang telah dimasukkan ke dalam proyek ini oleh tim inti, tetapi saya hanya berpikir bahwa kami dapat membuatnya lebih baik jika kami dapat benar-benar menyelaraskan dengan tujuan proyek ini. membiarkan pernyataan yang tidak terbukti menghalangi kemajuannya.

@wongjiahau kami tidak pergi ke pertemuan dan mengatakan "Daniel mengatakan jumlahnya 90%, itu di atas ambang batas kami 85%, jangan pernah lakukan fitur ini". Kami masih menyelidikinya dan kami sangat menyadari permintaan pengembang untuk itu, tetapi kami juga telah menguji seperti apa fitur ini dalam praktiknya dan saya dapat memberi tahu Anda bahwa itu tidak bagus.

Jika Anda akan menganalisis pernyataan seperti ini dari kami seperti ini, Anda hanya akan mendapatkan lebih sedikit pernyataan dari kami, karena kami memiliki hal yang lebih baik untuk dilakukan daripada disalahartikan secara aktif di internet.

4.0 jelas merupakan tonggak sejarah daripada "versi 3.9 berikutnya".

@typescript-bot buat rilis-4.0

Heya @DanielRosenwasser , saya sudah mulai membuat cabang release-4.0 untuk Anda. Berikut tautan ke tebakan terbaik saya di log .

@Kingwl jika ini adalah tonggak sejarah, lalu apa hal-hal besar itu atau setidaknya apa itu Fitur Pahlawan? Saya tidak melihat hal hebat seperti itu dalam daftar Fitur Bahasa di bagian atas masalah ini. Tidak ada yang tidak biasa dibandingkan dengan sebagian besar rilis 3.x.
Tentu saja Anda mungkin mengatakan bahwa itu hanya melanggar perubahan yang memerlukan rilis versi utama, tetapi kemudian sulit untuk menyebutnya "tonggak sejarah".

@wgebczyk Menurut pendapat saya, tupel variadik dengan elemen tupel berlabel adalah tonggak sejarah.

@wgebczyk Sudahlah. Tapi sebenarnya Variadic Tuples adalah.

@xiaoxiangmoe @Kingwl mile-stone? inci-batu.

Itu ada di sana: https://devblogs.microsoft.com/typescript/announcing-typescript-4-0-beta/#variadic -tuple-types
Kapan ini akan mencapai versi stabil? Saya tidak sabar untuk menerapkan ini dalam pengkodean setiap hari di VS Code.

@mk0y menurut pesan pembuka sekitar 18 Agustus.

@wgebczyk rilis kami berbasis waktu; setiap rilis berisi sekitar tiga bulan kerja tim. Kebijakan pembuatan versi tonggak pencapaian kami (n = n + 0,1) telah konsisten selama 20 rilis terakhir, jadi semoga ini akan berhenti menjadi kejutan bagi orang-orang di beberapa titik

Apakah Anda mempertimbangkan untuk mengizinkan tipe symbol untuk pengindeksan di rilis minor berikutnya? Bisakah Anda mengaktualisasikan dan menggabungkan permintaan tarik 26797 ?

Hai @DanielRosenwasser , Saya sudah mulai memperbarui nomor versi pada release-4.0 menjadi 4.0.1-rc untuk Anda. Berikut tautan ke tebakan terbaik saya di log .

@typescript-bot sinkronisasi rilis-4.0

Heya @DanielRosenwasser , saya sudah mulai menyinkronkan release-4.0 dengan master untuk Anda. Berikut tautan ke tebakan terbaik saya di log .

@typescript-bot sinkronisasi rilis-4.0

Heya @DanielRosenwasser , saya sudah mulai menyinkronkan release-4.0 dengan master untuk Anda. Berikut tautan ke tebakan terbaik saya di log .

@weswighammmmmmmmmmmmmmmmm , bot membenci saya ): ): ): ):

Sama sekali tidak terburu-buru, tetapi saya melakukannya secara manual dan mengajukan ini: https://github.com/microsoft/TypeScript/issues/39869

Apakah sudah ada peta jalan untuk setelah 4.0 di suatu tempat? Saya ingin mendongkrak #37582 karena permintaan semakin banyak (#39965, #38149, #27481, #39965, #38546). Sepertinya masalah cakupan yang cukup bagi saya.

Sebagai pembaruan, kami harus berpindah RC selama 2 hari untuk peluncuran situs web dan untuk perubahan lain kami merasa perlu mendarat di RC. Kami tidak mengantisipasi apa pun yang mendorong kami mundur lebih jauh, tetapi untuk amannya, kami akan memberi diri kami 2 hari lagi untuk mendapatkan umpan balik tentang RC, dan bertujuan untuk tanggal 20 sebagai gantinya.

@typescript-bot bump release-4.0

Hai @DanielRosenwasser , Saya sudah mulai memperbarui nomor versi pada release-4.0 menjadi 4.0.2 untuk Anda. Berikut tautan ke tebakan terbaik saya di log .

ini tanggal 20 agustus :)

Heh, masih 19 Agustus di sini, dan bahkan 20 menit dari sekarang saya pikir Anda harus menunggu lebih lama. Kami memiliki rilis malam di npm jika Anda tidak dapat meluangkan waktu lagi! 😄.

Di tunggu rilisnya, udah keluar di npm :)

@typescript-bot bump release-4.0

Hai @DanielRosenwasser , Saya sudah mulai memperbarui nomor versi pada release-4.0 menjadi 4.0.3 untuk Anda. Berikut tautan ke tebakan terbaik saya di log .

@typescript-bot bump release-4.1

Hai @DanielRosenwasser , Saya sudah mulai memperbarui nomor versi pada release-4.1 menjadi 4.1.1-rc untuk Anda. Berikut tautan ke tebakan terbaik saya di log .

Oh tidak

@typescript-bot bump release-4.0

Hai @DanielRosenwasser , Saya sudah mulai memperbarui nomor versi pada release-4.0 menjadi 4.0.4 untuk Anda. Berikut tautan ke tebakan terbaik saya di log .

@typescript-bot bump release-4.0

Hai @DanielRosenwasser , Saya sudah mulai memperbarui nomor versi pada release-4.0 menjadi 4.0.5 untuk Anda. Berikut tautan ke tebakan terbaik saya di log .