TypeScript 7: Compiler Go yang Mempercepat Build dan CI

TypeScript 7 membuat type-check dan build terasa lebih ringan, terutama saat project sudah besar dan CI mulai sering menjadi tempat menunggu. Compiler native berbasis Go memproses pekerjaan yang dulu membebani tsc dengan lebih cepat, termasuk pemeriksaan tipe, project references, watch mode, dan language tooling di editor.

Kamu tetap perlu membaca klaim “10x lebih cepat” dengan konteks yang tepat. Angka itu datang dari benchmark repository besar. Hasil project kamu dipengaruhi struktur dependency, ukuran codebase, konfigurasi, jumlah core CPU, dan kapasitas RAM. Untuk monorepo atau aplikasi yang menunggu type-check selama puluhan detik, perbedaannya biasanya langsung terasa.

Yang perlu kamu kuasai sebelum pindah:

• bagian workflow yang benar-benar mendapat manfaat;
• perubahan konfigurasi yang dapat memutus build;
• cara menjaga tooling lama tetap berjalan saat compiler baru mulai dipakai.

TypeScript 7 mempercepat validasi. Pipeline yang rapi tetap menentukan apakah kecepatan itu benar-benar berguna.

TypeScript 7 mempercepat pekerjaan compiler

TypeScript 7 memakai compiler native berbasis Go. Perubahan ini tidak mengubah cara kamu memakai interface, generic, union type, utility type, atau JSX. Yang berubah adalah mesin di balik tsc: proses membaca file, membangun dependency graph, memeriksa tipe, menghasilkan JavaScript, serta melayani diagnostic di editor.

Compiler sebelumnya berjalan sebagai JavaScript. Pendekatan itu stabil dan berhasil membawa TypeScript ke banyak ekosistem, tetapi batasnya mulai terasa di repository besar. Type-checking tidak hanya mencari typo. Compiler harus melacak import, symbol, tipe yang saling bergantung, declaration file, project references, dan relasi antarpaket.

Dengan Go, pekerjaan berat itu berjalan sebagai kode native dan bisa memakai beberapa core CPU. Arah teknis serta benchmark resminya dijelaskan dalam pengumuman TypeScript 7.

TypeScript 7 mempercepat proses pengembangan dan validasi kode. Ia tidak membuat runtime aplikasi di browser atau Node.js otomatis lebih cepat.

Kalau aplikasi lambat karena query database, bundle terlalu besar, request API berantai, atau cache buruk, sumber masalahnya tetap ada di layer tersebut. Yang berubah, kamu bisa menemukan dan menguji perbaikan lebih cepat karena type-check tidak lagi terlalu membebani workflow.

Angka 10x perlu dibaca dengan konteks

Klaim percepatan hingga 10 kali bukan target wajib bagi setiap project. Repository kecil yang sebelumnya selesai type-check dalam satu detik tetap mendapat manfaat, tetapi perbedaan beberapa ratus milidetik tidak selalu terasa besar.

Benchmark resmi memberi gambaran yang lebih berguna.

Percepatan paling besar biasanya muncul pada monorepo, project references, declaration emit, serta CI yang menjalankan type-check penuh di setiap pull request. Tim VS Code juga mendokumentasikan dampak migrasi mereka pada laporan adopsi TypeScript 7.

Mulai dari data repository kamu sendiri.

time npx tsc --noEmit
time npm run build
time npm run test

Simpan hasilnya sebelum migrasi. Setelah itu, bandingkan durasi tiap job CI. Jika type-check turun dari dua menit menjadi 15 detik, tetapi pipeline masih menghabiskan 20 menit karena test e2e, kamu sudah punya arah jelas untuk perbaikan berikutnya.

Catatan: Jangan mengejar angka benchmark dengan menaikkan worker secara agresif. Worker tambahan dapat mempercepat build, tetapi juga menaikkan pemakaian RAM.

Editor ikut terasa lebih ringan

Build hanya salah satu bagian dari waktu tunggu. Dalam kerja harian, kamu lebih sering berurusan dengan editor: auto-import, Go to Definition, Find All References, diagnostic, dan watch mode.

TypeScript 7 membuat language tooling lebih siap menghadapi repository besar. Dampak yang umum terasa:

• error tipe muncul lebih cepat;
• auto-import lebih sigap;
• navigasi kode tidak terlalu tersendat;
• project load lebih singkat;
• watch mode lebih stabil;
• perubahan lintas package lebih cepat diproses.

flowchart LR
	A["Kamu mengubah kode"] --> B["Language server"]
	B --> C["Type-check paralel"]
	C --> D["Diagnostic editor"]
	C --> E["Build dan emit"]
	E --> F["CI"]

Ini makin penting saat tim memakai coding agent untuk membuat patch atau refactor. Agent dapat menghasilkan banyak perubahan dengan cepat. Tanpa validasi cepat, patch yang belum diperiksa justru menumpuk dan menyulitkan review. TypeScript 7 membuat type-check penuh lebih realistis dijalankan pada setiap perubahan besar.

Peringatan: TypeScript memeriksa kontrak tipe. Ia tidak menggantikan unit test, integration test, pemeriksaan keamanan, atau review dependency.

Perubahan tsconfig.json yang perlu kamu bereskan

Migrasi paling aman tidak dimulai dari TypeScript 5.x langsung ke 7. Naikkan project ke TypeScript 6 lebih dulu, selesaikan deprecation, lalu lanjutkan ke versi 7. Jalur ini membuat error lebih mudah dipisahkan dan ditangani.

Jangan mematikan strict

Project lama sering menghindari strict karena error yang muncul cukup banyak. Biasanya error itu menunjukkan masalah yang memang sudah ada: nilai null tidak ditangani, parameter implisit bocor, atau API mengembalikan tipe terlalu longgar.

Baca juga Panduan Lengkap Ponytail: Skill AI Agar Ngoding Kayak Developer Senior

Jangan mematikan strict hanya agar build kembali hijau. TypeScript 7 membuat biaya validasi lebih rendah. Gunakan peluang itu untuk mempertegas kontrak API.

{
 "compilerOptions": {
 "strict": true,
 "target": "es2023",
 "module": "nodenext",
 "moduleResolution": "nodenext"
 }
}

Untuk aplikasi berbasis Vite atau bundler modern lain, moduleResolution: "bundler" sering lebih sesuai. Project Node.js yang memakai ESM umumnya lebih aman menggunakan nodenext.

Konfigurasi lama perlu diganti

TypeScript 7 menghentikan dukungan untuk beberapa konfigurasi lama seperti target: "es5", moduleResolution: "node", moduleResolution: "node10", moduleResolution: "classic", baseUrl, serta format module amd, umd, systemjs, dan none.

Kalau project masih membutuhkan output untuk browser lama, pindahkan urusan downleveling ke bundler atau transpiler yang memang dirancang untuk target itu. Jangan mempertahankan konfigurasi compiler lama hanya karena masih pernah dipakai.

Tetapkan rootDir dan types

Dua properti ini sering menjadi sumber error setelah migrasi.

{
 "compilerOptions": {
 "rootDir": "./src",
 "outDir": "./dist",
 "types": ["node", "vitest/globals"]
 },
 "include": ["src"]
}

rootDir menjaga struktur output tetap konsisten. Tanpa pengaturan ini, file src/index.ts dapat berubah menjadi dist/src/index.js saat pipeline lama mengharapkan dist/index.js.

Properti types membuat global seperti process, describe, atau it tetap tersedia bila memang dibutuhkan. Hindari types: ["*"] sebagai jalan pintas. Daftarkan tipe yang benar-benar dipakai supaya sumber global type tetap jelas.

Tooling yang belum siap perlu tetap memakai TypeScript 6

TypeScript 7.0 belum menyediakan Compiler API publik yang stabil untuk semua kebutuhan tooling. Project yang hanya memakai tsc untuk type-check dan emit umumnya lebih mudah bermigrasi. Batasnya muncul ketika project memakai tool yang mengimpor package typescript secara programatis.

Audit bagian berikut sebelum berpindah penuh:

• custom transformer;
• generator kode internal;
• plugin lint type-aware;
• tool berbasis ts-morph;
• tooling Vue, Svelte, Astro, MDX, atau Angular template;
• extension editor internal;
• workflow declaration emit khusus.

Framework dengan template tidak hanya memproses file .ts atau .tsx. Mereka juga perlu memahami binding, slot, metadata komponen, dan aturan framework. Itu sebabnya tidak semua workflow langsung mendapat manfaat penuh dari TypeScript 7.

Pola paling aman adalah menjalankan TypeScript 6 dan 7 berdampingan selama masa transisi.

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

{
 "scripts": {
 "typecheck": "tsc --noEmit",
 "typecheck:legacy": "tsc6 --noEmit"
 }
}

Menjalankan dua compiler sementara bukan tanda migrasi gagal. Ini cara menjaga validasi tetap berjalan saat tooling pendukung belum sepenuhnya siap.

Kelebihan & Kekurangan

Kelebihan

• Type-check lebih cepat untuk repository menengah hingga besar.
• CI lebih singkat sehingga pull request tidak terlalu lama tertahan.
• Editor lebih responsif saat mencari referensi atau memuat project.
• Watch mode lebih nyaman untuk kerja harian.
• Instalasi tetap sederhana karena package utama dan command tsc tidak berubah.

Kekurangan

• Konfigurasi lama perlu diaudit sebelum upgrade.
• Compiler API belum siap untuk semua tool pada TypeScript 7.0.
• Framework template-oriented memerlukan pengujian ekstra.
• Paralelisme berlebihan dapat menghabiskan RAM.
• Project kecil tidak selalu merasakan lonjakan 10 kali.

Cara migrasi tanpa membuat pipeline berantakan

Kamu tidak perlu memindahkan seluruh monorepo dalam satu pull request. Cara itu justru membuat rollback dan debugging lebih sulit.

1. Naikkan project ke TypeScript 6 lebih dulu Bersihkan deprecation dan pastikan konfigurasi lama sudah tidak dipakai.

2. Catat baseline performa Ukur type-check, lint, test, build, serta job CI yang paling lambat.

3. Audit tsconfig.json dan tooling Cari target ES5, baseUrl, module resolution lawas, serta dependency yang memakai Compiler API.

4. Pasang TypeScript 7 di branch terpisah Jalankan pemeriksaan dasar sebelum mengubah workflow production.

npm install -D typescript
npx tsc --version
npx tsc --noEmit

5. Bandingkan hasil dengan TypeScript 6 Jalankan dua versi compiler untuk tahap sensitif. Perbedaan error lebih mudah ditelusuri saat diff masih kecil.

6. Uji editor dan CI Cek auto-import, diagnostic, lint, test runner, declaration emit, bundling, serta cache CI.

7. Migrasikan package bertahap Mulai dari package yang tidak memakai tooling khusus, lalu perluas setelah hasilnya stabil.

flowchart TD
	A["TypeScript 6 siap"] --> B["Ukur baseline"]
	B --> C["Audit config dan tooling"]
	C --> D["Pasang TypeScript 7"]
	D --> E["Type-check dan test"]
	E --> F{"Tool kompatibel?"}
	F -- "Belum" --> G["Gunakan tsc6"]
	F -- "Sudah" --> H["Migrasi bertahap"]
	G --> H
	H --> I["Pantau CI dan editor"]

Tip: Pisahkan perubahan tsconfig.json, pembaruan dependency, dan aktivasi TypeScript 7 ke pull request berbeda. Review lebih cepat dan rollback lebih aman.

Atur paralelisme sesuai kapasitas mesin

TypeScript 7 menyediakan --checkers, --builders, dan --singleThreaded. Ketiganya berguna, tetapi tidak perlu langsung dipakai dengan angka tertinggi.

--checkers untuk type-check paralel

npx tsc --noEmit --checkers 8

Flag ini mengatur jumlah worker pemeriksa tipe. Mesin dengan banyak core bisa mendapat manfaat, tetapi setiap worker juga memakai memori. Mulai dari nilai default, ukur hasilnya, lalu naikkan perlahan.

--builders untuk project references

npx tsc --build --builders 4 --checkers 4

Pada monorepo, builder dapat membangun beberapa project references sekaligus. Kombinasi builder dan checker punya efek besar. Runner CI kecil bisa justru melambat jika terlalu banyak proses saling berebut CPU dan RAM.

--singleThreaded untuk diagnosis

npx tsc --noEmit --singleThreaded

Gunakan mode ini saat kamu ingin mereproduksi masalah atau membandingkan hasil tanpa paralelisme. Ini bukan pilihan utama untuk CI production, tetapi berguna saat investigasi.

CI cepat tetap membutuhkan urutan yang tepat

TypeScript 7 dapat menghapus satu bottleneck besar, tetapi pipeline tetap akan terasa lambat jika lint, type-check, test, bundling, dan deploy dicampur menjadi satu command panjang. Ketika satu tahap gagal, developer terpaksa menunggu proses lain selesai hanya untuk mengetahui sumber masalah.

Pisahkan tahap validasi agar hasilnya mudah dibaca dan cache lebih efektif.

{
 "scripts": {
 "typecheck": "tsc --noEmit",
 "lint": "eslint.",
 "test": "vitest run",
 "build": "vite build",
 "verify": "npm run lint && npm run typecheck && npm run test"
 }
}

Peringatan: Cache dependency tidak menggantikan type-check. Cache memangkas instalasi dan build yang dapat digunakan ulang, tetapi kontrak tipe tetap harus diperiksa ketika source code berubah.

TypeScript 7 tidak menggantikan bundler dan test runner

esbuild, SWC, Vite, ESLint, dan test runner tetap punya peran masing-masing. TypeScript 7 mempercepat type-check penuh, bukan menghapus kebutuhan tool lain.

Baca juga 9Router untuk Coding: AI Gateway Lokal agar Tidak Mudah Kena Rate

Pola kerja yang sehat tetap sederhana: gunakan tsc --noEmit untuk kontrak tipe, bundler untuk output production, linter untuk konsistensi kode, dan test runner untuk memastikan aplikasi bekerja seperti yang diharapkan.

Saat type-check penuh sudah jauh lebih cepat, kamu punya alasan kuat untuk menjalankannya lebih sering. Validasi tidak lagi harus ditunda hanya karena terlalu mahal secara waktu.

Cepat, Tapi Tetap Rapi

• Point: TypeScript 7 mempercepat type-check, bukan runtime aplikasi yang kamu jalankan.
• Point: Perbedaannya paling terasa pada monorepo, CI, dan repository besar.
• Point: Ukur baseline project sendiri sebelum mengejar angka benchmark publik.
• Point: Audit tsconfig.json agar target, module, dan tipe global tidak bermasalah.
• Point: Gunakan TypeScript 6 sementara jika tooling masih memakai Compiler API.
• Point: Atur worker paralel sesuai CPU dan RAM, bukan sekadar angka tertinggi.
• Point: Pisahkan lint, type-check, test, dan build agar error cepat terbaca.

TypeScript 7 bikin validasi kode jauh lebih ringan, tetapi migrasinya tetap perlu rapi. Kalau konfigurasi, tooling, dan CI sudah diuji bertahap, kamu bisa menikmati build lebih cepat tanpa mengorbankan kualitas kode.

Checklist

• Baca juga referensi otoritatif: id.
• Setup: Buat branch khusus sebelum memasang TypeScript 7.
• Baseline: Catat waktu type-check, lint, test, build, dan CI.
• Config: Audit tsconfig.json serta ganti konfigurasi yang sudah usang.
• Compatibility: Petakan tooling yang masih membutuhkan Compiler API TypeScript 6.
• Verify: Jalankan tsc --noEmit dan bandingkan hasilnya dengan versi lama.
• Secure: Jangan mematikan type-check atau menambah any demi CI hijau.
• Test: Uji editor, lint, test runner, declaration emit, dan bundling.
• Ship: Migrasikan package bertahap setelah pipeline tetap stabil.
• Referensi resmi: Announcing Typescript 7 0.