TypeScript 7.0 diumumkan

(devblogs.microsoft.com)

4 poin oleh GN⁺ 3 jam lalu | 2 komentar | Bagikan ke WhatsApp

TypeScript 7.0 adalah rilis yang mem-porting toolchain ke kode native berbasis Go, dan biasanya memberikan peningkatan kecepatan 8~12x pada build penuh proyek besar
tsc baru diinstal seperti sebelumnya melalui paket npm typescript, dan dukungan editor berjalan sebagai language server berbasis LSP di VS Code, Visual Studio, WebStorm, dan lainnya
Waktu build berkurang besar pada codebase seperti vscode, sentry, bluesky, playwright, dan tldraw, dan di beberapa lingkungan total penggunaan memori juga menurun
TypeScript 7.0 masih belum memiliki API pemrograman yang stabil, sehingga alat yang menanamkan TypeScript seperti typescript-eslint, Vue, MDX, Astro, Svelte, dan pemeriksaan tipe template Angular masih perlu menjalankan TypeScript 6.0 secara paralel
Karena ada default baru dan opsi yang dihapus, menerapkan perubahan TypeScript 6.0 terlebih dahulu akan memudahkan transisi, dan API baru dijadwalkan hadir di TypeScript 7.1

TypeScript native berbasis Go

TypeScript 7.0 adalah port native dari toolchain TypeScript, menggunakan codebase baru yang ditulis dalam Go
Porting dilakukan dengan mempertahankan struktur dan logika codebase lama semaksimal mungkin agar konsistensi hasil dan kompatibilitas antara dua compiler tetap terjaga
Codebase baru ini menghasilkan build penuh yang umumnya 8~12x lebih cepat berkat kecepatan kode native, multithreading berbasis shared memory, dan berbagai optimasi
Instalasi tetap bisa dilakukan lewat npm seperti sebelumnya

npm install -D typescript

Setelah instalasi, executable tsc baru dapat digunakan di workspace dan dijalankan dengan npx tsc

Memperpendek feedback loop pengembangan

TypeScript terlibat di banyak tahap proses pengembangan seperti pemuatan editor, cari semua referensi, autocomplete, diagnosis, tsc, dan mode --watch
TypeScript 7 memperpendek feedback loop dengan mengurangi waktu tunggu di seluruh proses ini
Pada codebase VS Code, waktu hingga error pertama terlihat saat membuka file yang bermasalah turun dari sekitar 17,5 detik menjadi kurang dari 1,3 detik, atau lebih dari 13x lebih cepat
Dukungan editor berbasis LSP, dan language server baru memanfaatkan multithreading untuk menangani permintaan paralel dengan cepat
Pengguna VS Code dapat memasang ekstensi khusus TypeScript 7, dan dalam beberapa minggu ke depan dukungan TypeScript 7 juga akan dimasukkan ke VS Code itu sendiri
Versi terbaru Visual Studio akan mengaktifkan TypeScript 7 secara otomatis tergantung workspace

Kinerja build dan hasil memori

Perbandingan waktu build penuh antara TypeScript 6 dan 7 pada codebase open source besar adalah sebagai berikut

Codebase	TypeScript 6	TypeScript 7	Peningkatan kecepatan
vscode	125.7 detik	10.6 detik	11.9x
sentry	139.8 detik	15.7 detik	8.9x
bluesky	24.3 detik	2.8 detik	8.7x
playwright	12.8 detik	1.47 detik	8.7x
tldraw	11.2 detik	1.46 detik	7.7x

Pada build yang sama, TypeScript 7 umumnya juga menunjukkan total penggunaan memori yang lebih rendah

Codebase	TypeScript 6	TypeScript 7	Perubahan memori
vscode	5.2GB	4.2GB	-18%
sentry	4.9GB	4.6GB	-6%
bluesky	1.8GB	1.3GB	-26%
playwright	1.0GB	0.9GB	-11%
tldraw	0.6GB	0.5GB	-15%

Validasi di codebase nyata dan masukan dari tim

Proyek TypeScript menjalankan puluhan ribu pengujian yang terakumulasi selama lebih dari 10 tahun pada setiap commit ke branch main
Selain pengujian tersebut, TypeScript 7 juga divalidasi pada codebase nyata milik tim besar di dalam dan luar perusahaan
Di internal Microsoft, TypeScript 7 divalidasi oleh tim Loop, Office, PowerBI, Teams, dan Xbox
Di luar Microsoft, Bloomberg, Canva, Figma, Google, Lattice, Linear, Miro, Notion, Sentry, Slack, Vanta, Vercel, VoidZero, dan lainnya mengujinya pada codebase mereka dan memberikan masukan
Language server baru mengurangi lebih dari 80% perintah language server yang gagal dan lebih dari 60% crash server dibanding TypeScript 6.0
Masukan dari tim nyata mencakup contoh berikut
- Slack melaporkan waktu merge queue berkurang 40% dengan TypeScript 7, dan waktu pemeriksaan tipe di CI turun dari sekitar 7,5 menit menjadi 1,25 menit
- Vanta mencatat peningkatan kecepatan build hingga 9x pada salah satu proyek besarnya
- Tim Microsoft News Services menghemat 400 jam waktu tunggu build CI per bulan
- Canva melaporkan waktu hingga error pertama terlihat di editor turun dari sekitar 58 detik menjadi 4,8 detik

Menjalankan TypeScript 6.0 secara paralel

TypeScript 7.0 masih belum menyertakan API
API baru yang berbeda dijadwalkan hadir di TypeScript 7.1
Sampai saat itu, TypeScript 6.0 dan 7.0 dapat dijalankan secara paralel untuk alat yang membutuhkan akses terprogram ke compiler
Paket kompatibilitas baru @typescript/typescript6 menyediakan executable tsc6 dan mengekspor ulang API TypeScript 6.0
Untuk alat seperti typescript-eslint yang langsung mengimpor typescript sebagai peer dependency, penggunaan npm alias direkomendasikan

npm install -D typescript@npm:@typescript/typescript6

Untuk memakai API TypeScript 6 bersama tsc dari TypeScript 7, alias dapat diatur seperti berikut

{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  }
}

Paket @typescript/native-preview yang lama telah menyediakan build nightly dari codebase baru TypeScript 7, dan mencatat lebih dari 8,5 juta unduhan per minggu
Ke depan, build nightly akan dilanjutkan melalui tag next pada paket standar typescript

npm install -D typescript@next

Opsi kontrol paralelisasi

TypeScript 7.0 menjalankan beberapa tahap seperti parsing, pemeriksaan tipe, dan emit secara paralel
Parsing dan emit mudah dijalankan secara independen per file, sehingga dapat diskalakan di codebase besar dengan overhead yang relatif rendah
Flag eksperimental baru --checkers, --builders, dan --singleThreaded mengatur perilaku paralelisasi

`--checkers`

TypeScript 7.0 membuat sejumlah tetap worker pemeriksaan tipe, dan selalu membagi pekerjaan dengan cara yang sama untuk file input yang sama agar hasilnya tetap konsisten
Jumlah default worker pemeriksaan tipe adalah 4, dan bisa disesuaikan dengan --checkers
Hasil pada mesin yang sama saat menggunakan --checkers 8 adalah sebagai berikut

Codebase	TypeScript 6	TypeScript 7 `--checkers 8`	Peningkatan kecepatan
vscode	125.7 detik	7.51 detik	16.7x
sentry	139.8 detik	12.08 detik	11.6x
bluesky	24.3 detik	2.01 detik	12.1x
playwright	12.8 detik	1.16 detik	11x
tldraw	11.2 detik	1.06 detik	10.6x

Menaikkan --checkers dapat mempercepat build dengan memanfaatkan lebih banyak core CPU, tetapi biasanya disertai peningkatan penggunaan memori
- Pada CI runner dengan core CPU dan memori terbatas, nilainya dapat diturunkan untuk menghindari overhead yang tidak perlu
- --checkers 1 pada dasarnya membuat pemeriksaan tipe berjalan single-thread dan menghilangkan pekerjaan duplikat
- Dalam kasus yang jarang terjadi, perubahan jumlah --checkers dapat mengungkap hasil yang bergantung pada urutan, sehingga menetapkan jumlah checker yang tetap di seluruh lingkungan build dapat membantu
--builders
- --builders mengontrol jumlah builder project reference yang dapat dijalankan secara bersamaan saat menjalankan --build
- Ini bisa sangat membantu terutama pada monorepo dengan banyak proyek
- Menaikkan nilainya dapat mempercepat build, tetapi juga dapat meningkatkan penggunaan memori
- Ada efek perkalian dengan --checkers, jadi --checkers 4 --builders 4 dapat menjalankan hingga 16 pemeriksa tipe secara bersamaan
- Perubahan jumlah --builders, tidak seperti --checkers, seharusnya tidak menghasilkan hasil yang berbeda
- Build project reference pada dasarnya dibatasi oleh graf dependensi proyek
--singleThreaded
- --singleThreaded membuat seluruh compiler berjalan dalam satu thread
- Ini dapat berguna untuk debugging, membandingkan performa TypeScript 6 dan 7, orkestrasi build paralel eksternal, dan lingkungan dengan sumber daya yang sangat terbatas
- Flag ini tidak hanya membatasi jumlah worker pemeriksa tipe menjadi 1, tetapi juga membuat parsing dan emit dijalankan pada satu thread

Mode `--watch` baru

TypeScript 7 sepenuhnya membangun ulang mode --watch
--watch yang baru menyediakan pemantauan file lintas platform yang efisien dan stabil berdasarkan file-watcher milik Parcel bundler
Pustaka standar Go tidak memiliki API pemantauan file bawaan, dan library pihak ketiga yang ditinjau memiliki masalah pada stabilitas, performa, dukungan lintas platform, dan integrasi dengan alat build
Pendekatan polling murni memang berjalan di berbagai sistem operasi, tetapi biaya komputasinya tinggi pada proyek besar dengan banyak dependensi node_modules
Tim TypeScript mem-porting @parcel/watcher, yang telah digunakan di VS Code, ke Go, dan memakai shim assembly minimal untuk menghindari dependensi pada toolchain C++
Watcher ini adalah paket independen, dan membawa peningkatan penggunaan sumber daya di berbagai platform untuk mode --watch TypeScript 7

Perubahan default dan kompatibilitas TypeScript 6.0

TypeScript 7.0 dibuat agar kompatibel dengan pemeriksaan tipe dan perilaku command line TypeScript 6.0
Kode yang dapat dikompilasi bersih di TypeScript 6.0 dengan flag stableTypeOrdering aktif dan ignoreDeprecations tidak disetel seharusnya dikompilasi sama di TypeScript 7.0
TypeScript 7.0 mengadopsi default baru dari TypeScript 6.0, dan menghasilkan hard error untuk flag serta sintaks yang deprecated di TypeScript 6.0
Perubahan utama pada default konfigurasi adalah sebagai berikut
- Default strict adalah true
- Default module adalah esnext
- Default target adalah versi ECMAScript stabil saat ini tepat sebelum esnext
- Default noUncheckedSideEffectImports adalah true
- Default libReplacement adalah false
- Default stableTypeOrdering adalah true dan tidak dapat dimatikan
- Default rootDir adalah ./
- Default types adalah [], dan perilaku sebelumnya dapat dipulihkan dengan ["*"]
Perubahan pada rootDir dan types disebut sebagai perubahan yang paling mungkin mengejutkan
- Proyek yang tsconfig.json-nya berada di luar direktori sumber seperti src perlu menyetel rootDir secara eksplisit agar struktur direktori lama tetap dipertahankan
- Proyek yang bergantung pada deklarasi global tertentu perlu mencantumkan paket @types yang diperlukan di types

{
  "compilerOptions": {
    "rootDir": "./src"
  },
  "include": ["./src"]
}

{
  "compilerOptions": {
    "types": ["node", "jest"]
  }
}

Perilaku yang dihapus atau menjadi hard error

Di TypeScript 7.0, berbagai opsi dan sintaks yang deprecated di TypeScript 6.0 tidak lagi didukung
Item utamanya adalah sebagai berikut
- target: es5 tidak didukung
- downlevelIteration tidak didukung
- moduleResolution: node/node10 tidak didukung, disarankan nodenext dan bundler
- module: amd, umd, systemjs, none tidak didukung, disarankan esnext atau preserve bersama resolusi modul berbasis bundler atau browser
- baseUrl tidak didukung, paths dapat diperbarui menjadi path relatif berbasis root proyek sebagai pengganti baseUrl
- moduleResolution: classic tidak didukung, disarankan bundler atau nodenext
- esModuleInterop dan allowSyntheticDefaultImports tidak dapat disetel ke false
- alwaysStrict dianggap true dan tidak dapat disetel ke false
- Kata kunci module tidak dapat digunakan dalam deklarasi namespace
- Kata kunci asserts tidak dapat digunakan dalam import, dan perlu memakai with mengikuti perubahan sintaks import attribute ECMAScript
- Di bawah skipDefaultLibCheck, direktif /// <reference no-default-lib /> tidak lagi dihormati
- Jika ada tsconfig.json di direktori saat ini, build command line tidak dapat menerima path file, dan memerlukan --ignoreConfig eksplisit

Perubahan pada template literal type dan dukungan JavaScript

TypeScript 7.0 menangani Unicode code point dengan lebih alami dalam inferensi template literal type

type HeadTail<S> = S extends `${infer Head}${infer Tail}` ? [Head, Tail] : never;

type Result = HeadTail<"😀abc">;
// 7.0: ["😀", "abc"]
// sebelumnya: ["\ud83d", "\ude00abc"]

Sebelumnya, "😀" dipecah menjadi dua bagian surrogate pair mengikuti perilaku indexing UTF-16 JavaScript
Perilaku baru ini lebih sesuai dengan intuisi yang memperlakukan "😀" sebagai satu unit, seperti for...of atau [...str]
Ini dapat menjadi breaking change untuk manipulasi string tingkat tipe yang sengaja memodelkan UTF-16 code unit
Dukungan JavaScript dikerjakan ulang agar lebih konsisten dengan cara TypeScript menganalisis file
- Nilai tidak dapat digunakan pada posisi tipe dan harus memakai typeof someValue
- @enum tidak lagi diperlakukan secara khusus
- ? tunggal tidak dapat digunakan sebagai tipe dan harus memakai any
- @class tidak membuat fungsi menjadi constructor, dan harus memakai deklarasi class
- Postfix ! tidak didukung
- Nama tipe harus didefinisikan di dalam tag @typedef
- Sintaks fungsi gaya Closure tidak lagi didukung dan harus memakai sintaks singkat TypeScript
Beberapa pola JavaScript seperti aliasing this dan penugasan ulang penuh prototype fungsi juga tidak lagi diperlakukan secara khusus
Perbedaan antara TypeScript 6.0 dan 7.0 dirangkum lebih rinci di CHANGES.md

Fitur editor dan batasan

TypeScript 7.0 menambahkan berbagai fitur editor yang sempat absen setelah beta
Termasuk auto import, hover yang dapat diperluas, inlay hint, code lens, go-to-source-definition, JSX linked editing, dan tag completion
Fitur seperti semantic highlighting, “sort imports”, dan “remove unused imports” yang sempat hilang dari TypeScript 7.0 beta juga ikut dimasukkan
Untuk kualitas language server, infrastruktur pengujian dan diagnostik dibangun ulang, dan kini memungkinkan fuzz test terhadap basis kode TypeScript·JavaScript utama di GitHub

Keterbatasan saat ini pada workflow bahasa bawaan

Workflow yang menggunakan Vue, MDX, Astro, Svelte, dan lainnya kemungkinan besar belum bisa memanfaatkan TypeScript 7
Pemeriksaan tipe template khusus seperti template Angular juga kemungkinan besar belum bisa menggunakan TypeScript 7
Alasan utamanya adalah karena TypeScript 7 masih belum mengekspos programming API yang stabil
Alat seperti Volar, yang menyematkan TypeScript ke dalam compiler dan language service mereka sendiri, saat ini tidak punya pilihan selain bergantung pada TypeScript 6.0
Tim TypeScript memandang masalah ini sebagai keterbatasan pada titik waktu tertentu, dan berencana bekerja sama dengan para maintainer proyek terkait untuk memastikan dukungan TypeScript 7
Sampai saat itu, penggunaan TypeScript 7 direkomendasikan untuk skenario yang tidak memerlukan language server plugin
Proyek Angular dapat memakai tsc dari TypeScript 7 di CLI untuk deteksi error cepat di seluruh proyek, dan tetap memakai TypeScript 6.0 untuk dukungan editor
Vue, MDX, Astro, Svelte, dan lainnya masih perlu terus memakai TypeScript 6.0 untuk sementara waktu
Di VS Code, Anda bisa kembali ke TypeScript 6.0 melalui perintah “Disable TypeScript 7 Language Server”

Rencana ke depan

Rilis TypeScript 7.0 merupakan milestone utama dari native port yang telah menjadi fokus proyek TypeScript selama lebih dari setahun
Setelah 7.0, mereka berencana kembali ke pengerjaan fitur baru, peningkatan kemudahan penggunaan, peningkatan performa tambahan, dan implementasi API baru untuk ekosistem
Seperti sebelum TypeScript 7.0, mereka memperkirakan akan merilis fitur baru setiap 3~4 bulan
TypeScript 7.1 direncanakan menghadirkan penutupan kesenjangan untuk membantu transisi komunitas serta menyediakan API baru

2 komentar

GN⁺ 3 jam lalu

Opini Hacker News

Berdasarkan pengujian internal, angka peningkatan kecepatan TypeScript 7 adalah sebagai berikut

Codebase TypeScript 6 TypeScript 7 Speedup

vscode 125.7s 10.6s 11.9x

sentry 139.8s 15.7s 8.9x

bluesky 24.3s 2.8s 8.7x

playwright 12.8s 1.47s 8.7x

tldraw 11.2s 1.46s 7.7x

Timnya luar biasa bisa mencapai hasil sebesar ini sambil melakukan migrasi secara bertanggung jawab. Semoga Bun melihat ini dan belajar. Yang membuat penasaran adalah apa dampaknya pada tooling di bawahnya yang perlu membangun codebase TypeScript, seperti tsdown atau esbuild, dan apakah TS 7 bisa dipakai bersama tsdown saat ini
- esbuild sama sekali tidak bergantung pada TypeScript, jadi tidak ada masalah. Untuk tsdown, tergantung apakah memakai --isolatedDeclarations; kalau tidak, cukup pasang TypeScript 6 berdampingan seperti panduan di blog
- Penasaran apakah maksudnya migrasi Bun tidak bertanggung jawab
Dulu ada masa ketika orang berdebat bahwa tipe tidak sepadan dengan usaha yang diperlukan. Hal terbaik dari TypeScript adalah, di atas segalanya, ia mempopulerkan tipe
- Saya tidak terlalu ingat ada orang yang membenci tipe. Yang banyak orang benci adalah static typing, lebih tepatnya typing yang statis dan eksplisit
  Misalnya, saya beberapa kali mendengar orang berkata Python tidak bisa dipakai karena tidak punya tipe, padahal itu tidak masuk akal. Python adalah bahasa strongly typed, hanya saja sekaligus dynamically typed.
  Memang ada bahasa yang benar-benar tidak punya tipe, atau yang biasanya disebut “stringly typed”. AREXX yang saya utak-atik waktu kecil memperlakukan semua nilai sebagai string meski terlihat seperti angka, dan sebagian besar tool Unix CLI seperti sed juga bisa dianggap begitu. Namun sebagian besar perdebatan soal tipe berkisar pada bahasa dynamically typed seperti Python, dan hampir tidak pernah saya melihat orang mengatakan bahasa weakly typed atau untyped cocok untuk proyek skala besar. Sebaliknya, saya sering mendengar orang keliru menyebut Python “tidak punya tipe” lalu mengatakan itu tidak bisa dipakai untuk proyek besar, dan sebagai orang yang benar-benar membangun proyek besar dengan Python, itu membingungkan
- Sistem tipe zaman dulu memang kurang bagus. Dipaksa memakai hierarki class untuk mengekspresikan tipe “OR” seperti sum types itu menyakitkan. Bahasa modern yang punya sum types seperti TypeScript, Rust, Swift, dan Kotlin jauh lebih nyaman
- Secara pribadi, saya pernah tiga kali berbicara dengan orang yang kurang lebih berkata, “Saya tidak pernah mengalami kesalahan typing di JavaScript.” Dua di antaranya adalah orang-orang yang karyanya saya hormati, jadi sulit memahami bagaimana mereka bisa punya posisi seperti itu
- Menurut saya algebraic data types dan pattern matching mengubah permainan. Tanpa perlu sejauh Haskell pun, tipe tiba-tiba menjadi jauh lebih berguna
  Dulu paparan terhadap tipe kebanyakan berasal dari C++/Java, dan khususnya C++ sulit dijadikan contoh baik untuk apa pun selain cara membuat bahasa yang kelewat rumit. Begitu melihat tipe diterapkan dengan baik, jauh lebih mudah untuk meyakinkan orang
- Sekarang tinggal menunggu DependentTypeScript
Yang benar-benar mengesankan di sini adalah tim hebat yang secara bersamaan memelihara dua codebase terpisah demi sistem tipe paling maju yang diketahui umat manusia. Menantikan penulisan ulang dengan Rust juga
- Saya tidak yakin penulisan ulang dengan Rust akan bermakna. Go cepat untuk coding, dan mudah mengimplementasikan ulang TypeScript 1:1 sambil melihat kodenya
  Rust akan butuh waktu pengembangan jauh lebih lama. Rust mungkin bisa 20% lebih cepat daripada Go, tetapi peningkatan yang didapat dari TypeScript ke Go saja sudah sangat besar. Di vscode mungkin Rust bisa menghasilkan 14x alih-alih 11x dengan Go, tetapi Go saja sudah cukup untuk membuat perbedaan besar
- Mungkin bisa disebut yang paling kompleks, tetapi saya tidak yakin apakah itu sistem tipe “paling maju”. Tidak ada jawaban pasti untuk gelar itu, tetapi salah satu bahasa proof assistant tampaknya kandidat yang lebih masuk akal
  Bukan bermaksud meremehkan sistem tipe TypeScript; itu memang pekerjaan yang sangat menarik
- Steve Francia, pembuat Hugo dan beberapa proyek Go besar, menulis tentang Go di era agen: https://spf13.com/p/go-the-agentic-language/
- Penasaran apa sebenarnya maksud “sistem tipe paling maju yang diketahui umat manusia”
- Setahu saya mereka mempertimbangkan Rust dan lainnya dengan serius sebelum memilih Go. Saya tidak ingat semua alasannya, tetapi dijelaskan cukup rinci di posting blog aslinya
Setelah beberapa tahun memakai TypeScript, rasanya sangat merepotkan harus menambahkan anotasi tipe sendiri di Python dan membawa fitur bahasa dasar seperti abc
Menarik, tetapi sekarang Node menghapus anotasi tipe TypeScript secara native, jadi saya hampir tidak menjalankan TSC. Saya hanya menjalankannya ketika perlu memeriksa output statis compiler untuk bagian yang tidak ikut diperbarui setelah membuat perubahan besar yang bersifat breaking
Kode frontend yang akan dikirim ke browser juga mengandalkan penghapusan tipe oleh Node
- Benar, tetapi di sisi lain editor menjalankan TypeScript language server sepanjang hari. CI mungkin juga begitu, dan AI agent juga kemungkinan akan melakukannya sebelum yakin dengan pekerjaan yang baru saja dibuat
Senang melihat sintaks tipe JSDoc terus mendapat perhatian. Ini cara favorit saya memakai TypeScript untuk proyek pribadi. Beberapa perubahan sintaks mungkin akan merepotkan saat update, tetapi sebagian besar terlihat menuju arah yang lebih baik
- Untung TypeScript memakai JSDoc, bukan format XML mengerikan yang dipakai bahasa-bahasa Microsoft lainnya
  [1] https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...
Salah satu penderitaan besar TypeScript adalah sulitnya menyesuaikan cakupan konfigurasi tsconfig seperti lib dan types untuk sebagian proyek
Proyeknya adalah aplikasi web, tetapi karena vite.config.ts, Playwright, dan unit test, tipe Node ikut masuk ke sisi tooling IDE. Bahkan jika menambahkan API Node ke komponen React, tsc tidak protes.
Saat ini, untuk mengisolasi library DOM dan library Node, dibutuhkan spaghetti project references, banyak sekali file tsconfig.json dan file keluaran tsbuildinfo, dan memakai project references sambil menghindari keluaran tipe juga merepotkan
- Saya setuju ini bagian yang benar-benar menyakitkan. Saya memakai nx, dan itu menangani hal-hal seperti ini. Playwright adalah proyek terpisah dengan tsconfig sendiri, dan semuanya mewarisi tsconfig root
  Bahkan untuk satu aplikasi, saya lebih suka nx, dan kode bersama saya pindahkan ke “library”. Saya memakai library yang tidak dibuild, dan untuk proyek besar ini cukup bagus
TypeScript compiler API memang belum ada, tetapi katanya sedang dikerjakan, jadi saya menantikannya
- Rencananya akan masuk di 7.1
Melihat grafik yang menunjukkan penggunaan memori turun dan performa naik besar, rasanya untuk sisi server seharusnya memakai Go, bukan TypeScript
- Pertama-tama, di sisi server yang dijalankan bukan TypeScript. Yang dijalankan adalah kode hasil transformasi atau JavaScript, apa pun execution engine yang dipakai
  Dan meski sekarang ada banyak pilihan, saya tidak begitu paham mengapa masih ada orang yang memulai proyek baru dengan TS/JS/Python
- Bisa jadi karena dapat berbagi tipe atau modul dengan proyek frontend. Bisa juga karena pada aplikasi yang tidak CPU-intensive hampir tidak ada bedanya, atau karena sudah familier dan menyukainya. Ekosistem library-nya juga sangat besar
- Ini adalah performa waktu build, bukan performa waktu eksekusi
- Penting tidaknya perbedaan performa antara Go dan JS (Node, dll.) bergantung pada use case. Untuk compiler TypeScript jelas penting, tetapi untuk aplikasi CRUD mungkin sama sekali tidak penting
- Karena jika memungkinkan, lebih mudah bekerja dengan satu bahasa utama
Selamat untuk tim TypeScript. Ada hal yang bisa saya tulis panjang atau rekam sebagai audio, tetapi singkatnya ekosistem JavaScript/TypeScript mirip dengan bekerja dengan kayu
Anda bisa membuat papan laminasi murah, barang ala Ikea. Kalau dalam kode, itu mungkin aplikasi vibe coding yang tidak orisinal.
Sebaliknya, furnitur buatan tangan kelas atas atau gedung tinggi dari kayu juga memungkinkan. Misalnya memakai kayu muda lalu membuat balok tahan api dengan teknik sambungan khusus dan laminasi. Di ekosistem JavaScript/TypeScript pun, bisa lahir hasil berkualitas tinggi yang dibuat dengan semangat craftsmanship, sambil memakai AI seperti mesin perkakas yang kuat. Jika Anda punya keberanian untuk membuat sesuatu dan menjalankannya, terimalah ekosistem TypeScript/JavaScript.

Codebase	TypeScript 6	TypeScript 7	Speedup
vscode	125.7s	10.6s	11.9x
sentry	139.8s	15.7s	8.9x
bluesky	24.3s	2.8s	8.7x
playwright	12.8s	1.47s	8.7x
tldraw	11.2s	1.46s	7.7x

GN⁺ 3 jam lalu

Komentar di Lobste.rs

Saya paham alasannya, tetapi menarik bahwa mereka berpindah dari compiler yang self-hosted ke compiler yang tidak self-hosted
Biasanya hampir selalu arahnya sebaliknya, jadi ini alur yang jarang terlihat
- Saya rasa kita perlu lebih sering melihat arah seperti ini. Tidak semua bahasa cocok untuk menulis compiler
  Self-hosting memberi tekanan kuat agar bahasa berevolusi menjadi bahasa yang lebih baik untuk menulis compiler, dan itu mungkin tidak selalu arah yang tepat
- Menakjubkan bahwa perancang dan implementor bahasa memahami bahwa bahasa mereka sendiri tidak sempurna untuk semua keperluan
Meski tidak menulis kode dengan TypeScript, karena VSCode sendiri ditulis dengan TypeScript, saya penasaran apakah peningkatan ini juga berdampak pada kecepatan VSCode
Atau apakah hanya berdampak pada ekstensi bahasa TypeScript
- Yang menjadi lebih cepat adalah compiler-nya, bukan secara ajaib menghasilkan kode yang lebih cepat
- Ini hanya berlaku untuk ekstensi bahasa TypeScript
- TypeScript dikompilasi menjadi JavaScript. Saat VSCode dijalankan, node.js dan Chromium menjalankan kode JavaScript
  Yang menjadi lebih cepat di sini hanyalah compiler yang menerima kode TypeScript lalu mengubahnya menjadi JavaScript, dan proses ini terjadi di pipeline build sebelum Microsoft mendistribusikan executable VSCode
  Satu kemungkinan pengecualian adalah server LSP TypeScript juga bisa menjadi lebih cepat, karena server itu memang mem-parsing kode TypeScript saat berjalan. Namun ini terpisah dari fakta bahwa VSCode ditulis dengan TypeScript
- Compiler TypeScript sebenarnya tidak melakukan banyak hal. Karena prinsip bahwa tsc tidak boleh menyentuh kode yang sedang diproses selain hal minimal seperti penghapusan tipe, cukup banyak hal yang ditandai sebagai WONTFIX
  Jadi saya memperkirakan karakteristik performa alat-alat yang dibuat dengan TypeScript hampir tidak akan berubah
Ini tips kecil yang saya dapat secara pribadi. Proyek yang sedang saya tangani saat ini memakai TS 5, tetapi seperti yang bisa diduga, saya tidak ingin memakai itu di nvim
Jadi saya terlebih dahulu memasang TS 7 dengan mise, lalu membuat symbolic link tsgo di dalam node_modules/.bin yang menunjuk ke TS yang dipasang lewat mise
Karena nvim-lspconfig masih memakai nama berkas lama tsgo dari masa pratinjau teknis, nvim akhirnya menjalankan TS 7 yang sudah saya pasang, bukan TS lokal

TypeScript 7.0 diumumkan

TypeScript native berbasis Go

Memperpendek feedback loop pengembangan

Kinerja build dan hasil memori

Validasi di codebase nyata dan masukan dari tim

Menjalankan TypeScript 6.0 secara paralel

Opsi kontrol paralelisasi

`--checkers`

`--builders`

`--singleThreaded`

Mode `--watch` baru

Perubahan default dan kompatibilitas TypeScript 6.0

Perilaku yang dihapus atau menjadi hard error

Perubahan pada template literal type dan dukungan JavaScript

Fitur editor dan batasan

Keterbatasan saat ini pada workflow bahasa bawaan

Rencana ke depan

2 komentar

Opini Hacker News

Komentar di Lobste.rs

TypeScript 7.0 diumumkan

TypeScript native berbasis Go

Memperpendek feedback loop pengembangan

Kinerja build dan hasil memori

Validasi di codebase nyata dan masukan dari tim

Menjalankan TypeScript 6.0 secara paralel

Opsi kontrol paralelisasi

--checkers

--builders

--singleThreaded

Mode --watch baru

Perubahan default dan kompatibilitas TypeScript 6.0

Perilaku yang dihapus atau menjadi hard error

Perubahan pada template literal type dan dukungan JavaScript

Fitur editor dan batasan

Keterbatasan saat ini pada workflow bahasa bawaan

Rencana ke depan

Bacaan terkait

2 komentar

Opini Hacker News

Komentar di Lobste.rs

`--checkers`

`--builders`

`--singleThreaded`

Mode `--watch` baru