TypeScript 6.0 RC: ciri-ciri, perubahan penting dan cara menyediakannya

Utama » Python » TypeScript 6.0 RC: ciri-ciri, perubahan penting dan cara menyediakannya

TypeScript 6.0 secara rasminya telah mencapai pencapaian Calon Pelepasan (RC), dan ia bukan sekadar kemas kini tambahan. Ini merupakan versi utama terakhir yang dijalankan pada pelaksanaan JavaScript pengkompil dan perkhidmatan bahasa yang telah lama wujud, sebelum projek ini beralih kepada enjin berasaskan Go yang baharu dalam TypeScript 7.0. Itu sahaja menjadikan 6.0 satu keluaran penting: ia merupakan jambatan yang perlu anda lalui sebelum segala-galanya di bawah hud berubah.

Anda boleh mula mencuba RC hari ini dengan memasangnya dari npm dengan:

npm install -D typescript@rc

Idea teras di sebalik TypeScript 6.0 ialah penyediaan dan penjajaranVersi ini melancarkan laluan dari 5.9 kepada 7.0, mengetatkan tetapan lalai, mengurangkan beban sejarah dan menambah beberapa ciri yang disasarkan yang sama ada mencerminkan tingkah laku masa hadapan atau mendedahkan keupayaan JavaScript akan datang seperti Temporal, API ES2025 dan kaedah "upsert" Peta. Sepanjang proses, terdapat beberapa tweak sistem jenis halus, bendera pengkompil baharu dan tetapan lalai konfigurasi yang pasti akan menjejaskan projek sebenar—terutamanya di sekitar types, rootDir, dan ketegasan.

TypeScript 6.0 sebagai jambatan kepada 7.0 berasaskan Go

TypeScript 6.0 direka bentuk secara eksplisit sebagai keluaran utama terakhir pada pangkalan kod JavaScript sedia adaPasukan TypeScript telah menulis semula pengkompil dan perkhidmatan bahasa ke dalam motor nativo en Go, memanfaatkan prestasi natif dan paralelisme memori kongsi. Enjin baharu itu akan dilancarkan sebagai TypeScript 7.0 dan seterusnya, dan 6.0 berada betul-betul di hadapannya sebagai peringkat peralihan.

Kebanyakan perubahan dan penamatan terkini dalam 6.0 adalah untuk memastikan peningkatan 7.0 anda pada masa hadapan dapat bertahan.Pilihan yang tidak dapat disokong dengan cekap dalam seni bina asli, sistem modul lama dan kebiasaan lama sama ada sedang dialih keluar atau ditanda dengan jelas sebagai tidak digunakan lagi dengan pintu keluar: anda boleh menetapkan "ignoreDeprecations": "6.0" dalam anda tsconfig.json untuk menyekat diagnostik penamatan dalam 6.0. Tetapi bendera itu tidak akan membantu anda dalam 7.0—pilihan tersebut dirancang untuk hilang sepenuhnya.

Jika anda tergoda untuk "menunggu sehingga 7.0" sebelum melakukan sebarang pembersihan konfigurasi, itu adalah satu perangkap.6.0 RC ialah versi di mana anda sepatutnya membaikinya tsconfig, normalkan jenis dan tangani bendera yang tidak digunakan lagi. Membuat dua lompatan besar (5.x → 7.0) akan sentiasa lebih menyakitkan daripada pergi ke 5.x → 6.0 → 7.0 dengan perubahan yang lebih kecil dan terkawal.

Apa yang berubah sejak beta 6.0

Antara beta dan RC, pasukan TypeScript memberi tumpuan terutamanya pada penyelarasan tingkah laku dengan enjin 7.0 masa hadapan., serta beberapa tweak yang disasarkan dalam pemeriksaan jenis dan penaipan DOM.

Satu perubahan penting memberi kesan kepada pemeriksaan jenis ungkapan fungsi yang dihantar kepada panggilan generik, terutamanya dalam konteks JSX. Apabila fungsi generik dipanggil dengan panggilan balik (contohnya dalam React atau komponen JSX lain), RC mengetatkan inferens supaya ia mencerminkan dengan lebih tepat apa yang akan dilakukan oleh 7.0. Dalam praktiknya, anda mungkin perasan bahawa sesetengah panggilan yang bergantung pada inferens tersirat kini memerlukan argumen jenis eksplisit untuk memastikan pemeriksaan jenis berjalan lancar, tetapi anda juga akan menemui lebih banyak pepijat tulen dalam kod sedia ada.

Penamatan sintaks penegasan import juga telah dilanjutkanTypeScript sudah memberi amaran terhadap yang lama import ... assert {...} sintaks dalam import statik disebabkan oleh cadangan ECMAScript yang beralih kepada atribut import dengan with. Kini, penyusutan itu juga terpakai kepada import dinamik yang menggunakan import() dengan objek penegasan seperti import(..., { assert: {...}}). Hala tujunya jelas: beralih untuk mengimport atribut di mana-mana sahaja.

Jenis pustaka DOM telah disegarkan semula agar sepadan dengan piawaian platform web semasa, termasuk kemas kini pada API berkaitan Temporal dalam konteks web. Jika anda membina aplikasi pelayar, anda mendapat manfaat daripada penaipan yang lebih tepat dan perkakasan editor yang lebih baik di sekitar API yang lebih baharu ini.

Kurang sensitiviti konteks untuk fungsi yang tidak pernah digunakan this

TypeScript 6.0 memperkenalkan perubahan yang halus tetapi sangat praktikal dalam cara ia mengendalikan fungsi tanpa this penggunaan semasa inferens jenisDari segi sejarah, fungsi dengan parameter yang kekurangan jenis eksplisit boleh dianggap "sensitif secara kontekstual", yang bermaksud parameter dan this jenis bergantung pada tempat ia digunakan. Itu memberi kesan kepada inferens generik dan boleh menyebabkan tingkah laku ganjil bergantung pada sintaks fungsi.

Pertimbangkan pembantu generik yang menggunakan pasangan pengeluar dan pengguna:

declare function callIt<T>(obj: {
  produce: (x: number) => T,
  consume: (y: T) => void,
}): void;

// Arrow functions: everything infers fine
callIt({
  produce: (x: number) => x * 2,
  consume: y => y.toFixed(),
});

// Flipped property order still fine with arrows
callIt({
  consume: y => y.toFixed(),
  produce: (x: number) => x * 2,
});

Tetapi dengan sintaks kaedah, tingkah laku sebelumnya mungkin mengejutkanLogik yang sama, yang ditulis sebagai kaedah, mungkin gagal apabila sifat disusun semula, kerana TypeScript melangkau fungsi "sensitif kontekstual" apabila membuat kesimpulan terhadap argumen generik. Kaedah secara tersirat mempunyai this parameter, yang meletakkan mereka dalam kategori sensitif itu walaupun this sebenarnya tidak pernah dirujuk.

Dalam 6.0, fungsi yang tidak pernah dibaca this kini dianggap kurang sensitif secara kontekstualDengan kata lain, jika pengkompil melihatnya this Jika tidak digunakan langsung di dalam fungsi, ia tidak akan menghukum fungsi tersebut semasa inferens. Ini bermakna sintaks kaedah dan sintaks anak panah kini jauh lebih konsisten dalam senario inferens generik, dan tingkah laku pelik "berfungsi dalam satu tertib sifat, gagal dalam tertib sifat yang lain" akan hilang dalam kes ini.

Perubahan ini meningkatkan keutamaan calon untuk inferens jenis: fungsi tanpa digunakan this menjadi sumber maklumat keutamaan yang lebih tinggi apabila membuat kesimpulan hujah jenis seperti TKesannya kurang misteri unknown jenis dan inferens yang lebih stabil merentasi faktor semula. Kerja ini disumbangkan oleh Mateusz Burzyński.

Sokongan untuk Nod #/ import sublaluan

Ciri "import subpath" Nod membolehkan pakej menentukan alias import dalaman melalui imports bidang di package.jsonAlias ​​ini memudahkan import dengan mengelakkan laluan relatif dalam. Sebelum ini, setiap kunci sublaluan mesti mempunyai sekurang-kurangnya satu segmen selepas yang awal #, yang merupakan batasan kecil tetapi menjengkelkan bagi orang yang biasa menggunakan konvensyen bundler seperti @/....

TypeScript 6.0 kini menyokong import sublaluan yang bermula dengan #/, sejajar dengan tingkah laku Node 20 yang lebih baharu. Ini bermakna anda boleh menggunakan konfigurasi seperti:

{
  "name": "my-package",
  "type": "module",
  "imports": {
    "#": "./dist/index.js",
    "#/*": "./dist/*"
  }
}

Dengan persediaan ini, modul di dalam pakej—dan juga pengguna—boleh mengimport melalui ringkas #/... awalan bukannya laluan relatif yang panjang seperti ../../utils.jsTypeScript memahami corak ini apabila --moduleResolution ditetapkan untuk node20, nodenext, Atau bundler, mencerminkan semantik Node moden. Penambahbaikan ini telah dilaksanakan oleh penyumbang magic-akari.

Menggunakan --moduleResolution bundler bersama --module commonjs

Sebelum ini, --moduleResolution bundler hanya boleh digunakan dengan --module esnext or preserveDengan penghinaan terhadap yang lebih tua node/node10 mod resolusi modul, banyak projek memerlukan laluan migrasi yang sesuai dengan output CommonJS semasa mereka.

TypeScript 6.0 kini membolehkan penggabungan --moduleResolution bundler bersama --module commonjsGabungan ini selalunya merupakan batu loncatan praktikal untuk pangkalan kod yang masih memancarkan CommonJS tetapi bergerak ke arah aliran kerja berpusatkan bundler atau logik resolusi yang lebih baharu. Dari situ, projek boleh merancang migrasi jangka panjang kepada sama ada:

• module: "preserve" bersama moduleResolution: "bundler" untuk aplikasi web yang dibundel dan persediaan yang serupa, atau
• module: "nodenext" untuk persekitaran yang menyasarkan Node.js moden secara langsung.

Perubahan ini amat relevan untuk pasukan yang meninggalkan moduleResolution: node di belakang tetapi belum bersedia untuk menerima sepenuhnya output ESM. Ia memberi anda laluan berfasa dan bukannya tebing.

. --stableTypeOrdering bendera untuk meniru pesanan 7.0

Salah satu peningkatan seni bina utama yang akan datang dalam TypeScript 7.0 ialah pemeriksaan jenis selariMenjalankan berbilang pemeriksa secara selari bermakna bahagian program yang berbeza boleh dilawati dalam susunan yang berbeza. Jika ID jenis dan susunan simbol bergantung pada susunan lawatan, anda boleh berakhir dengan susunan kesatuan bukan deterministik, susunan harta, dan juga perbezaan diagnostik yang jarang berlaku.

Versi TypeScript yang lebih lama memberikan ID jenis dalaman berdasarkan susunan pertemuanID tersebut kemudiannya digunakan untuk menyusun perkara seperti jenis dan sifat kesatuan. Itulah sebabnya suntingan yang nampaknya tidak berbahaya—seperti memperkenalkan yang baharu const sebelum fungsi sedia ada—boleh membalikkan susunan kesatuan literal dalam yang dipancarkan .d.ts fail, atau ubah cara sesetengah jenis dicetak dalam editor anda.

TypeScript 7.0 bertukar kepada susunan berasaskan kandungan yang deterministik untuk objek dalamanSetiap jenis atau simbol disusun mengikut strukturnya, bukan susunan lawatan sampingan, jadi program yang sama akan menghasilkan susunan yang sama secara konsisten tanpa mengira susunan paralelisme atau kompilasi. Itu menghapuskan misteri "mengapa kesatuan saya tiba-tiba berubah?".

Untuk membantu anda membandingkan tingkah laku antara 6.0 dan 7.0, RC memperkenalkan --stableTypeOrderingApabila bendera ini diaktifkan, TypeScript 6.0 menggunakan algoritma susunan jenis deterministik yang sama seperti yang digunakan oleh 7.0. Hasilnya ialah perbezaan yang jauh lebih sedikit dalam fail pengisytiharan yang dipancarkan dan perbandingan yang lebih boleh diramal antara output 6.x dan 7.x.

Walau bagaimanapun, determinisme tidak bebas. Mendayakan --stableTypeOrdering boleh memperlahankan pemeriksaan jenis sehingga kira-kira 25% bergantung pada pangkalan kod anda. Ia bertujuan sebagai bantuan diagnostik dan migrasi, bukan tetapan prestasi selama-lamanya.

Jika anda hanya melihat ralat jenis apabila --stableTypeOrdering dihidupkan, ia biasanya bermaksud kod anda sebelum ini bergantung pada susunan jenis separa tidak sengaja yang lama untuk inferens kepada "hanya berfungsi". Pembetulan biasanya melibatkan menjadikan jenis eksplisit—menambah argumen jenis pada panggilan generik yang bermasalah atau memberi anotasi pembolehubah dengan antara muka tertentu dan bukannya bergantung sepenuhnya pada inferens untuk objek yang kompleks.

Baru es2025 pilihan sasaran dan lib

TypeScript 6.0 menambah es2025 pilihan untuk kedua-duanya target and libWalaupun ES2025 tidak memperkenalkan sintaks teras baharu berbanding tahun-tahun sebelumnya, ia turut memasukkan beberapa API piawai yang sebelum ini dikawal selia di belakang esnext.

Dengan menyasarkan atau memasukkan es2025, anda mendapat taipan terkini untuk terbina dalam baharu seperti RegExp.escape, dan beberapa API telah dialihkan daripada esnext ke dalam es2025Itu termasuk perkara seperti Promise.try, pembantu iterator dan tambahan Set kaedah yang telah mencapai kematangan spesifikasi penuh. Kerja ini disumbangkan oleh Kenta Moriuchi.

Kisah yang lebih luas ialah lalai target dalam 6.0 kini menjejaki tahun ECMAScript semasa, yang pada masa ini secara efektifnya membawa anda ke ES2025 apabila anda tidak menentukan sasaran. Itu lebih sepadan dengan realiti masa jalan malar hijau dan perkakasan moden.

Jenis terbina dalam untuk API Temporal

Cadangan Temporal yang telah lama dinanti-nantikan telah mencapai peringkat 3 dan dijangka akan menggantikan cadangan yang terkenal itu. Date API untuk kerja tarikh/masa yang seriusTypeScript 6.0 kini menghantar taipan kelas pertama untuk Temporal, jadi anda boleh mula menulis kod berasaskan Temporal dengan keselamatan jenis penuh dan sokongan editor.

Untuk mendayakan jenis Temporal, anda boleh menggunakannya --target esnext atau konfigurasikan libs anda secara eksplisit melalui sesuatu seperti:

{
  "compilerOptions": {
    "lib": 
  }
}

Atau anda boleh memilih untuk hanya memilih subset temporal dengan "esnext.temporal" jika anda mahukan konfigurasi yang lebih terperinci. Setelah diaktifkan, anda boleh menulis kod seperti berikut:

let yesterday = Temporal.Now.instant().subtract({
  hours: 24,
});

let tomorrow = Temporal.Now.instant().add({
  hours: 24,
});

console.log(`Yesterday: ${yesterday}`);
console.log(`Tomorrow: ${tomorrow}`);

Temporal sudah disokong dalam beberapa runtime dan boleh diisi secara poli dalam yang lain, jadi jenis-jenis ini benar-benar boleh digunakan hari ini. Dokumentasi sedang muncul di MDN (dengan beberapa jurang masih diisi). Penaipan telah disumbangkan oleh pengguna GitHub, Renegade334.

Sokongan Upsert: Map.getOrInsert and getOrInsertComputed

Pembangun JavaScript telah menulis corak “semak-kemudian-tetap-kemudian-dapatkan” secara manual pada Map selama bertahun-tahunCorak biasa menyemak sama ada kunci wujud, menetapkan lalai jika tidak, dan akhirnya mengembalikan nilai—plat boiler yang mudah salah atau diulang di mana-mana.

Cadangan "upsert" ECMAScript (kini peringkat 4) memperkenalkan getOrInsert and getOrInsertComputed on Map and WeakMapTypeScript 6.0 menambah sokongan jenis untuk kaedah ini dalam esnext lib, supaya anda boleh mula menulis lebih banyak upsert deklaratif dengan segera.

Dengan getOrInsert, corak berjela seperti ini:

function processOptions(compilerOptions: Map<string, unknown>) {
  let strictValue: unknown;
  if (compilerOptions.has("strict")) {
    strictValue = compilerOptions.get("strict");
  } else {
    strictValue = true;
    compilerOptions.set("strict", strictValue);
  }
  // ...
}

Boleh dilipat menjadi satu baris:

function processOptions(compilerOptions: Map<string, unknown>) {
  let strictValue = compilerOptions.getOrInsert("strict", true);
  // ...
}

Sahabatnya getOrInsertComputed sesuai untuk lalai yang mahal—ia memerlukan panggilan balik yang hanya dipanggil jika kunci hilang. Panggilan balik itu juga boleh menerima kunci sebagai parameter, membolehkan anda memperoleh lalai daripada kunci itu sendiri. Penaipan TypeScript menangkap tingkah laku ini dengan tepat, sekali lagi terima kasih kepada sumbangan daripada Renegade334.

RegExp.escape dan pembinaan regex yang lebih selamat

Jika anda pernah menggabungkan rentetan yang dibekalkan pengguna ke dalam ungkapan biasa, anda tahu anda sepatutnya mengecualikan aksara khas terlebih dahulu—tetapi kebanyakan pangkalan kod sama ada melaksanakan semula escaping dalam pembantu atau melupakannya sepenuhnya. Cadangan RegExp Escaping (kini peringkat 4) menyeragamkannya dengan RegExp.escape.

TypeScript 6.0 mendedahkan jenis untuk RegExp.escape di bawah es2025 libIni bermakna apabila anda menyasarkan atau memasukkan ES2025, anda boleh menulis pembantu seperti:

function matchWholeWord(word: string, text: string) {
  const escapedWord = RegExp.escape(word);
  const regex = new RegExp(`\\b${escapedWord}\\b`, "g");
  return text.match(regex);
}

Tidak perlu lagi fungsi pelepasan gulung tangan, dan TypeScript akan memahami sepenuhnya dan menyemak jenis API. Tambahan ini, seperti kerja sasaran ES2025, datang daripada Kenta Moriuchi.

dom lib kini merangkumi API iterasi dan async

Dari segi sejarah, TypeScript membahagikan sokongan iterator DOM kepada dom, dom.iterable, dan dom.asynciterableJika anda ingin mengulang NodeList or HTMLCollection bersama for...of, anda perlu ingat untuk menambah dom.iterable dalam anda "lib" konfigurasi di samping domIni merupakan punca kekeliruan yang biasa, terutamanya kerana semua pelayar moden menyokong iterables dan iterables asinkron pada koleksi DOM.

Dalam TypeScript 6.0, lib.dom.iterable.d.ts and lib.dom.asynciterable.d.ts digabungkan secara berkesan ke dalam lib.dom.d.ts. Maksudnya menggunakan "dom" alone kini memberi anda tingkah laku lelaran dan async lelaran secara lalai.

Anda masih boleh menyebut dom.iterable and dom.asynciterable dalam anda tsconfig, tetapi fail-fail tersebut kini merupakan cangkerang kosong. Jika konfigurasi anda sebelum ini kelihatan seperti ini:

{
  "compilerOptions": {
    "lib": 
  }
}

Anda boleh memudahkannya dengan selamat "dom", dan lelaran ke atas koleksi DOM seperti document.querySelectorAll("div") masih akan menyemak jenis:

for (const element of document.querySelectorAll("div")) {
  console.log(element.textContent);
}

Ini adalah pembersihan kecil tetapi dialu-alukan yang menyelaraskan lib DOM lalai dengan realiti pelayar semasa dan mengalih keluar gotcha lain daripada persediaan projek.

Lalai, penamatan dan perubahan yang tidak menentu dalam TypeScript 6.0

Selain API yang berkilat, 6.0 membuat beberapa perubahan paling berprinsip pada tetapan lalai TypeScript sejak 1.0Perubahan ini mencerminkan ekosistem JavaScript semasa: runtime malar hijau, ESM sebagai garis dasar, penggunaan bundler yang meluas dan minat yang tinggi terhadap penaipan dan prestasi yang ketat.

Pasukan ini mengetengahkan beberapa trend umum yang menyokong keputusan iniES5 dan pelayar legasi yang sebenar hampir tiada; sistem modul AMD/UMD adalah khusus; hampir semuanya dihantar sebagai modul sekarang; penaipan ketat adalah kebiasaan; dan prestasi perlu kekal diutamakan, terutamanya kerana 7.0 membawakan pemeriksaan selari.

Akibatnya, TypeScript 6.0 dan 7.0 sedang dibentuk dengan tetapan lalai moden dan kurang "injap pelepasan legasi"Untuk 6.0 RC, anda boleh menyenyapkan penafian buat sementara waktu dengan menetapkan "ignoreDeprecations": "6.0" dalam anda tsconfig, tetapi pilihan tersebut tidak akan wujud dalam 7.0. Sesetengah pelarasan boleh diautomasikan dengan alatan seperti eksperimental ts5to6 codemod, yang boleh membantu menulis semula perkara seperti baseUrl and rootDir konfigurasi merentasi sesuatu projek.

Dua pelarasan yang diperlukan oleh banyak projek dengan segera

Walaupun terdapat senarai penamatan yang panjang, dua perubahan konfigurasi berkemungkinan akan menjejaskan bilangan pangkalan kod terbesar:

• Tetapkan secara eksplisit types pelbagai (sangat kerap serta rangka kerja ujian anda). Tanpa ini, anda akan kehilangan jenis ambien yang disertakan secara automatik daripada @types/*.
• Ditetapkan secara eksplisit rootDir (biasanya "./src") jika anda bergantung pada "inferens punca lazim" yang lama. Jika tidak, struktur fail yang dipancarkan anda mungkin berubah dengan cara yang halus.

Simptom-simptom kehilangan types termasuk banjir ralat tentang global seperti process, fs, path, Atau describe tidak ditakrifkanSimptom-simptom perubahan rootDir lebih lanjut mengenai laluan output tanpa diduga memperoleh tambahan src segmen (contohnya dist/src/index.js bukan dist/index.js).

Lalai yang dikemas kini untuk projek moden

Beberapa pilihan pengkompil kini mempunyai nilai lalai baharu yang sepadan dengan cara kebanyakan aplikasi baharu dibina:

• strict kini lalai kepada trueMod ketat bukan lagi satu kemewahan ikut serta; ia adalah garis dasar. Jika sebelum ini anda bergantung pada tingkah laku yang tidak ketat, anda perlu menetapkan secara eksplisit "strict": false (walaupun anda akan terlepas kategori pemeriksaan keselamatan yang besar).
• module kini lalai kepada esnext, mencerminkan bahawa ESM ialah format modul yang dominan dan paling sesuai digunakan dengan bundler dan Node moden.
• target lalai kepada tahun ECMAScript semasa (berkesan ES2025 sekarang), mengakui bahawa kebanyakan penggunaan menyasarkan persekitaran malar hijau atau melalui bundler yang boleh menurunkan tahap lebih lanjut apabila benar-benar perlu.
• noUncheckedSideEffectImports kini true secara lalai, membantu anda mengesan kesalahan taip atau laluan buruk dalam import yang disertakan untuk kesan sampingan sahaja.
• libReplacement lalai kepada false, mengelakkan pelbagai penyelesaian modul tambahan yang gagal dan pemantauan overhead sehingga projek secara eksplisit memilih untuk menggunakan tingkah laku lib khusus.

Jika mana-mana lalai baharu ini melanggar binaan anda, semuanya boleh diatasi secara eksplisit dalam tsconfig.jsonTetapi tujuannya adalah agar projek baharu "melakukan perkara yang betul" tanpa konfigurasi tambahan.

rootDir kini lalai kepada direktori konfigurasi

Sebelum ini, jika anda tidak menyatakan rootDir, TypeScript cuba membuat kesimpulan tentang punca sumber yang sama berdasarkan semua fail bukan pengisytiharan dalam program. Itu menyukarkan untuk membuat penaakulan tentang sempadan projek dan memerlukan pengimbasan banyak laluan fail hanya untuk menentukan di mana emit harus di-root.

Dalam TypeScript 6.0, tetapan lalai rootDir hanyalah direktori yang mengandungi tsconfig.jsonTingkah laku inferens lama hanya terpakai apabila anda menjalankan tsc pada baris arahan tanpa sebarang tsconfig pada semua.

Perubahan ini bermakna projek dengan fail sumber yang lebih dalam daripada direktori konfigurasi harus ditetapkan secara eksplisit rootDirPersediaan biasa ialah:

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

Jika konfigurasi anda merujuk fail di atas tsconfig lokasi, anda juga perlu melanjutkan rootDir sewajarnya, Sebagai contoh "rootDir": "../src" untuk direktori sumber kongsi.

types kini lalai kepada array kosong

Ini boleh dikatakan perubahan yang paling memberi kesan untuk projek dunia sebenarDari segi sejarah, jika anda tidak menyatakan types in compilerOptions, TypeScript akan memasukkan secara automatik semua yang di bawah node_modules/@typesItu mudah, tetapi juga mahal dan rapuh: repo moden sering menarik ratusan @types pakej secara transitif.

Dalam TypeScript 6.0, types lalai kepada [], bermakna tiada pakej jenis ambien dimuatkan secara automatikAnda kini memilih untuk menyertai persekitaran global yang anda perlukan secara eksplisit, contohnya:

{
  "compilerOptions": {
    "types": 
  }
}

Ini boleh mengurangkan masa pembinaan sebanyak 20-50% dalam sesetengah projek, kerana pengkompil tidak lagi perlu merangkak melalui setiap fail deklarasi di bawah @typesJika anda benar-benar mahukan tingkah laku "muatkan semuanya" yang lama, anda boleh menentukan:

{
  "compilerOptions": {
    "types": 
  }
}

Jika anda tiba-tiba melihat ralat seperti “Tidak dapat mencari nama 'proses'” atau “Tidak dapat mencari modul 'fs'”, itulah isyarat anda untuk menambah node (dan sebarang jenis ujian/masa jalan lain yang anda andalkan) kepada anda types susunan.

Tidak digunakan lagi: target: es5 and --downlevelIteration

Penyasaran ES5 kini tidak lagi digunakanDengan setiap pelayar yang berkaitan menghantar ES2015+ selama bertahun-tahun dan Internet Explorer bersara, output ES5 tidak lagi dianggap berbaloi dengan kerumitan di dalam TypeScript itu sendiri. Sasaran yang paling rendah disokong pada masa hadapan ialah ES2015. Jika anda benar-benar mesti menghantar ES5, cadangannya adalah untuk menggunakan transpiler luaran (seperti Babel atau saluran paip bundler) sama ada pada sumber TS anda atau pada output TS.

. --downlevelIteration bendera juga tidak digunakan lagi, kerana satu-satunya kes penggunaannya yang bermakna adalah untuk melaraskan tingkah laku pancaran untuk sasaran ES5. Dalam TypeScript 6.0, tetapan downlevelIteration at all akan menghasilkan ralat pemberhentian. Jika anda menggunakan ES2015 atau lebih baharu, bendera tersebut tidak pernah memberi sebarang kesan.

Tidak digunakan lagi: --moduleResolution node dan warisan classic

. node (Aka node10) mod resolusi modul tidak lagi digunakanIa memodelkan tingkah laku Node 10 tetapi tidak sepadan dengan semantik ESM dan resolusi Node moden. Projek harus berhijrah ke mana-mana nodenext (untuk sasaran Nod langsung) atau bundler (untuk persekitaran yang dipacu oleh bundler seperti aplikasi web atau Bun).

Asal moduleResolution: classic strategi juga telah dihapuskanIni adalah kisah resolusi pra-Nod TypeScript. Hari ini, semua senario praktikal lebih baik dilayan oleh nodenext or bundler, jadi classic telah ditamatkan untuk mengurangkan kerumitan dan kes tepi.

Tidak lagi digunakan: AMD, UMD, SystemJS dan module: none

Berikut module nilai-nilai kini tidak lagi digunakan dan tidak disokong secara efektif:

• amd
• umd
• systemjs
• none

Format-format ini adalah kritikal dalam era pra-ESM, apabila pelayar web kekurangan sokongan modul asli dan pembangun bergantung pada AMD, UMD atau SystemJS untuk mengisi jurang tersebut. Hari ini, ESM plus bundler atau peta import mengendalikan hampir semua kes penggunaan sebenar dan "tiada" tidak pernah ditakrifkan dengan baik.

Jika anda masih menyasarkan format modul legasi ini, cadangannya adalah untuk berhijrah ke arah sasaran pemancar ESM dan bergantung pada bundler atau pengkompil alternatif untuk pembungkusan akhir—atau kekal pada TypeScript 5.x sehingga pelan migrasi disediakan. Sebagai sebahagian daripada pembersihan ini, yang lama amd-module arahan juga digugurkan.

Tidak digunakan lagi: baseUrl

. baseUrl pilihan telah lama menjadi sumber tingkah laku penyelesaian modul yang pelik dan sukar untuk dinyahpepijatBanyak projek menggunakannya semata-mata sebagai awalan untuk paths entri, tetapi TypeScript juga menganggapnya sebagai akar carian umum, menyebabkan import seperti "someModule" untuk menyelesaikan src/someModule.js tanpa diduga apabila semua yang dimaksudkan oleh pembangun adalah untuk menyokong alias tersuai seperti @app/*.

Dalam 6.0, baseUrl tidak lagi digunakan dan tidak akan digunakan sebagai root carianPemetaan laluan tidak diperlukan baseUrl untuk beberapa waktu, jadi migrasi yang disyorkan hanyalah melipat awalan ke dalam setiap paths entri. Contohnya:

// Before
{
  "compilerOptions": {
    "baseUrl": "./src",
    "paths": {
      "@app/*": ,
      "@lib/*": 
    }
  }
}

// After
{
  "compilerOptions": {
    "paths": {
      "@app/*": ,
      "@lib/*": 
    }
  }
}

Hanya dalam kes yang jarang berlaku di mana anda benar-benar menggunakannya baseUrl sebagai akar carian generik adakah anda perlu menghasilkan semula tingkah laku tersebut dengan pemetaan laluan catch-all seperti:

"paths": {
  "*": ,
  "@app/*": ,
  "@lib/*": 
}

Bagi kebanyakan pasukan, hanya membuang baseUrl dan penggarisan awalan dalam paths akan lebih jelas dan selamat.

Interop dan ketegasan: esModuleInterop, allowSyntheticDefaultImports, dan alwaysStrict

TypeScript 6.0 juga mengunci apa yang telah lama menjadi tingkah laku interop lalai yang disyorkanAnda tidak lagi boleh menetapkan esModuleInterop or allowSyntheticDefaultImports kepada falsePilihan ini pada asalnya dipilih untuk mengelakkan projek lama daripada rosak, tetapi memadamkannya hari ini sering membawa kepada masalah masa jalan yang halus apabila menggabungkan CommonJS dan ESM.

Dengan interop sentiasa diaktifkan, corak import tertentu mungkin perlu dikemas kini. Sebagai contoh:

// Old style with esModuleInterop: false
import * as express from "express";

// New style with modern interop always on
import express from "express";

. alwaysStrict bendera juga tidak boleh ditetapkan kepada false lagiTypeScript kini menganggap semantik mod ketat JavaScript secara menyeluruh, termasuk bagaimana perkataan yang dikhaskan dan this berkelakuan baik. Jika anda mempunyai kod yang benar-benar lama yang menggunakan perkataan yang dikhaskan seperti await or static sebagai pengecam, anda perlu menamakannya semula.

Tidak digunakan lagi: outFile, ruang nama legasi module kata kunci, dan import asserts

. --outFile pilihan dialih keluar dalam 6.0Menggabungkan berbilang input ke dalam satu pakej JS adalah kerja yang lebih baik dikendalikan oleh Webpack, Rollup, esbuild, Vite, Parcel atau alat yang serupa. TypeScript menggandakan pemeriksaan jenis dan pemancaran deklarasi dan bukannya cuba menjadi bundler.

Penggunaan legasi module untuk mengisytiharkan ruang nama kini merupakan satu ralat yang sukarTypeScript awal dibenarkan:

module Foo {
  export const bar = 10;
}

Sintaks moden yang disokong menggunakan namespace:

namespace Foo {
  export const bar = 10;
}

Perubahan ini perlu bagi mengelakkan pertembungan dengan potensi ECMAScript pada masa hadapan. module blok. Pengisytiharan modul ambien seperti declare module "some-module" { ... } kekal disokong sepenuhnya.

Import pernyataan menggunakan asserts juga tidak digunakan lagi, kerana cadangan asas berkembang menjadi atribut import menggunakan withKod seperti:

import blob from "./data.json" asserts { type: "json" };

Perlu dipindahkan ke borang baharu:

import blob from "./data.json" with { type: "json" };

Tidak digunakan lagi: no-default-lib rujukan dan senarai fail baris arahan dengan tsconfig

. /// <reference no-default-lib="true" /> arahan tidak lagi disokongIa sering disalahertikan. Jika anda perlu mengecualikan lib lalai, gunakan --noLib or --libReplacement sebaliknya, yang lebih jelas menyatakan niat pada peringkat konfigurasi.

Satu lagi punca kekeliruan yang berlarutan adalah bagaimana tsc melayan argumen fail eksplisit apabila tsconfig.json hadirSebelum ini, berjalan tsc foo.ts dalam direktori sedemikian akan mengabaikan fail konfigurasi secara senyap. Dalam 6.0, senario itu menghasilkan ralat eksplisit:

error TS5112: tsconfig.json is present but will not be loaded if files are specified on commandline. Use '--ignoreConfig' to skip this error.

Jika anda benar-benar mahu memintas konfigurasi dan hanya menyusun satu fail dengan lalai, anda kini boleh menggunakan tsc --ignoreConfig foo.ts untuk menjelaskan niat itu.

Bersedia untuk TypeScript 7.0

TypeScript 6.0 lengkap ciri dan kebanyakannya dalam mod penstabilanDari sini hingga ketersediaan umum, pasukan hanya menjangkakan pembetulan pepijat yang kritikal. Binaan setiap malam diterbitkan secara berkala dan pasukan juga menghantar versi setiap malam TypeScript 7.0 natif (berasaskan Go) yang akan datang berserta sambungan VS Code khusus untuk bereksperimen dengan enjin baharu.

Pelan tindakan itu sengaja ketat: 7.0 dijangka menyusul 6.0 tidak lama kemudian, jadi gelung maklum balas mengenai masalah peningkatan dan migrasi akan menjadi pendek. Jika anda melihat amaran penamatan dalam 6.0, cadangan yang kuat adalah untuk menanganinya sekarang dan bukannya menunggu sehingga 7.0 memaksa isu tersebut.

Aliran kerja praktikal untuk kebanyakan pasukan kelihatan seperti ini: naik taraf kepada TypeScript 6.0 RC, betulkan anda types and rootDir, menangani penolakan (atau sementara waktu menutupnya "ignoreDeprecations": "6.0" semasa anda mengulang), dan jalankan dengan --stableTypeOrdering jika anda perlu membandingkan output atau menyediakan saluran paip CI untuk susunan deterministik 7.0. Sebaik sahaja itu tersedia, lompatan ke pengkompil berasaskan Go sepatutnya terasa seperti peningkatan prestasi dan bukannya penulisan semula yang gagal.

Secara keseluruhannya, TypeScript 6.0 RC kurang mengenai sintaks yang cemerlang dan lebih kepada menetapkan pentas: kelajuan natif dalam 7.0, konfigurasi yang lebih bersih, lalai moden dan API piawai seperti terbina dalam Temporal dan ES2025 yang memudahkan pengekodan harian. Jika anda menerimanya sekarang, membetulkan bit bising dan bergantung pada lalai baharu, anda akan berada di tempat yang lebih baik apabila pengkompil natif tiba.