Ada cara mudah untuk mengkonfigurasi TypeScript untuk mempercepat kompilasi dan pengeditan. Dan semakin cepat diterapkan, semakin baik. Ada juga beberapa pendekatan populer untuk menyelidiki penyebab kompilasi dan pengeditan yang lambat, beberapa perbaikan dan cara umum untuk membantu tim TypeScript memecahkan masalah.

1. Menulis kode yang mudah dikompilasi

1.1. Lebih memilih antarmuka daripada persimpangan (intersection)

Lebih sering daripada tidak, alias sederhana untuk suatu tipe objek bertindak dengan cara yang sama seperti antarmuka.

interface Foo { prop: string }

type Bar = { prop: string };

Namun jika Anda memerlukan kombinasi dua atau lebih tipe, Anda bisa memperluasnya menggunakan antarmuka, atau membuat perpotongan tipe dalam alias. Perbedaan antara pendekatan ini penting.

Antarmuka membuat satu tipe objek datar yang mengekspos konflik properti yang biasanya penting untuk diselesaikan! Dan persimpangan hanya menggabungkan properti secara rekursif, dan dalam beberapa kasus menghasilkan never

. Selain itu, antarmuka ditampilkan lebih baik, sementara alias tipe untuk persimpangan tidak dapat ditampilkan di bagian persimpangan lainnya. Jenis hubungan antar antarmuka di-cache, tidak seperti jenis persimpangan. Perbedaan penting terakhir adalah ketika memvalidasi terhadap jenis persimpangan target, setiap komponen divalidasi sebelum divalidasi / diratakan.

Oleh karena itu, disarankan untuk memperluas tipe dengan interface

/ extends

daripada membuat persimpangan tipe.

- type Foo = Bar & Baz & {
-     someProp: string;
- }
+ interface Foo extends Bar, Baz {
+     someProp: string;
+ }

1.2. Menggunakan anotasi tipe

Menambahkan anotasi tipe, terutama untuk nilai yang dikembalikan, dapat menghemat banyak pekerjaan bagi compiler. Ini sebagian karena tipe bernama biasanya lebih padat daripada tipe anonim (yang dapat ditransmisikan oleh compiler), yang mengurangi waktu yang dibutuhkan untuk membaca dan menulis file deklarasi (misalnya, untuk build inkremental). Mentransmisi sangat mudah, jadi tidak perlu melakukannya secara universal. Tetapi akan berguna untuk mencoba ketika Anda menemukan fragmen yang lambat dalam kode Anda.

- import { otherFunc } from "other";
+ import { otherFunc, otherType } from "other";

- export function func() {
+ export function func(): otherType {
      return otherFunc();
  }

1.3. Preferensi untuk tipe dasar di atas beberapa tipe

Beberapa tipe adalah alat yang hebat: mereka memungkinkan Anda untuk mengekspresikan kisaran nilai yang mungkin untuk sebuah tipe.

interface WeekdaySchedule {
  day: "Monday" | "Tuesday" | "Wednesday" | "Thursday" | "Friday";
  wake: Time;
  startWork: Time;
  endWork: Time;
  sleep: Time;
}

interface WeekendSchedule {
  day: "Saturday" | "Sunday";
  wake: Time;
  familyMeal: Time;
  sleep: Time;
}

declare function printSchedule(schedule: WeekdaySchedule | WeekendSchedule);

Tapi semuanya ada harganya. Setiap kali sebuah argumen dilewatkan printSchedule

, itu harus dibandingkan dengan setiap elemen dari himpunan. Ini bukan masalah untuk dua elemen. Tetapi jika ada selusin elemen di set, itu dapat memperlambat kecepatan kompilasi. Misalnya, untuk menghilangkan elemen yang berlebihan, semuanya perlu dibandingkan secara berpasangan, ini adalah fungsi kuadrat. Pemeriksaan seperti itu dapat terjadi saat memotong himpunan besar, saat perpotongan untuk setiap elemen himpunan dapat menyebabkan tipe besar yang perlu dikurangi. Dan Anda dapat menghindari semua ini dengan menggunakan subtipe, bukan set.

interface Schedule {
  day: "Monday" | "Tuesday" | "Wednesday" | "Thursday" | "Friday" | "Saturday" | "Sunday";
  wake: Time;
  sleep: Time;
}

interface WeekdaySchedule extends Schedule {
  day: "Monday" | "Tuesday" | "Wednesday" | "Thursday" | "Friday";
  startWork: Time;
  endWork: Time;
}

interface WeekendSchedule extends Schedule {
  day: "Saturday" | "Sunday";
  familyMeal: Time;
}

declare function printSchedule(schedule: Schedule);

Contoh yang lebih realistis adalah saat mencoba membuat model semua jenis elemen DOM bawaan. Dalam hal ini, lebih disukai untuk membuat tipe dasar HtmlElement

dengan elemen yang sering, yang mengembang dengan DivElement

, ImgElement

dll., Daripada membuat himpunan yang berat DivElement | /*...*/ | ImgElement | /*...*/

.

2. Menggunakan tautan proyek

Saat membuat basis kode TypeScript besar, akan berguna untuk mengaturnya menjadi beberapa proyek independen . Masing-masing memiliki tsconfig.json

dependensinya sendiri dengan proyek lain. Ini dapat membantu menghindari mengunduh terlalu banyak file dalam satu kompilasi, dan juga mempermudah untuk mencampur dan mencocokkan skema basis kode yang berbeda.

Ada beberapa cara yang sangat sederhana untuk membagi basis kode Anda menjadi proyek . Misalnya, proyek untuk klien, proyek untuk server, dan proyek umum di antara mereka.

             ------------
              |          |
              |  Shared  |
              ^----------^
             /            \
            /              \
------------                ------------
|          |                |          |
|  Client  |                |  Server  |
-----^------                ------^-----

Tes juga dapat dipisahkan menjadi proyek terpisah.

             ------------
              |          |
              |  Shared  |
              ^-----^----^
             /      |     \
            /       |      \
------------  ------------  ------------
|          |  |  Shared  |  |          |
|  Client  |  |  Tests   |  |  Server  |
-----^------  ------------  ------^-----
     |                            |
     |                            |
------------                ------------
|  Client  |                |  Server  |
|  Tests   |                |  Tests   |
------------                ------------

Orang sering bertanya: "Seberapa besar seharusnya proyek itu?" Ini seperti bertanya, "Seberapa besar seharusnya suatu fungsi?" atau "Seberapa besar kelasnya?" Banyak hal bergantung pada pengalaman. Katakanlah Anda dapat membagikan kode JS / TS menggunakan folder, dan jika beberapa komponen cukup saling berhubungan untuk dimasukkan ke dalam satu folder, Anda dapat menganggapnya sebagai bagian dari proyek yang sama. Juga, hindari proyek besar atau kecil. Jika salah satu dari mereka lebih besar dari yang lainnya digabungkan, maka ini pertanda buruk. Sebaiknya juga tidak membuat lusinan project file tunggal karena hal ini meningkatkan overhead.

Anda dapat membaca tentang tautan lintas proyek di sini .

3. Konfigurasi tsconfig.json atau jsconfig.json

Pengguna TypeScript dan JavaScript selalu dapat menyesuaikan kompilasi mereka menggunakan file tsconfig.json. File Jsconfig.json juga dapat digunakan untuk menyesuaikan pengeditan JavaScript .

3.1. Mendefinisikan file

Selalu pastikan file konfigurasi Anda tidak mencantumkan terlalu banyak file sekaligus.

Anda tsconfig.json

dapat menentukan file proyek dengan dua cara:

daftar files

;
daftar include

dan exclude

;

Perbedaan utama antara keduanya adalah ia files

mendapat daftar jalur file sumber, sementara include

/ exclude

menggunakan pola globbing untuk mengidentifikasi file yang sesuai.

Dengan menentukan files

, kami mengizinkan TypeScript memuat file dengan cepat secara langsung. Ini bisa merepotkan jika proyek berisi banyak file dan hanya beberapa titik masukan tingkat tinggi. Juga mudah untuk lupa menambahkan file baru tsconfig.json

, dan kemudian Anda mengalami perilaku editor yang aneh.

include

/ exclude

tidak mengharuskan semua berkas ini diidentifikasi, tetapi sistem harus mendeteksinya dengan membuka direktori yang ditambahkan. Dan jika ada banyak , kompilasi mungkin melambat. Selain itu, terkadang kompilasi menyertakan banyak hal yang tidak perlu.d.ts

dan menguji file, yang juga dapat menurunkan kecepatan dan meningkatkan konsumsi memori. Terakhir, meskipun exclude

ada default yang sesuai, beberapa konfigurasi, seperti mono-repositories, memiliki folder "berat" seperti node_modules

itu yang akan ditambahkan pada waktu kompilasi.

Yang terbaik adalah melakukan ini:

Tentukan hanya folder input proyek Anda (misalnya, kode sumber yang ingin Anda tambahkan selama kompilasi dan analisis).
Jangan mencampur file sumber dari proyek berbeda dalam folder yang sama.
Jika Anda menyimpan pengujian dalam folder sumber yang sama, beri nama sehingga dapat dengan mudah dikecualikan.
Hindari membuat artefak perakitan besar dan folder ketergantungan seperti node_modules

.

Catatan: Tanpa daftar, exclude

folder node_modules

akan dikecualikan secara default. Dan jika daftar akan ditambahkan, penting untuk menunjukkan secara eksplisit di dalamnya node_modules

.

Berikut contohnya tsconfig.json

:

{
    "compilerOptions": {
        // ...
    },
    "include": ["src"],
    "exclude": ["**/node_modules", "**/.*/"],
}

3.2. Kontrol atas penambahan @types

Secara default, TypeScript secara otomatis menambahkan semua node_modules

paket yang ditemukan di folder @types

, apakah Anda mengimpornya atau tidak. Ini untuk membuat fungsi tertentu “berfungsi” saat menggunakan Node.js, Jasmine, Mocha, Chai, dll., Karena alat / paket ini tidak diimpor, tetapi dimuat ke lingkungan global.

Terkadang logika ini dapat memperlambat kompilasi dan pengeditan program. Dan bahkan menyebabkan konflik deklarasi di berbagai paket global yang menyebabkan kesalahan seperti ini:

Duplicate identifier 'IteratorResult'.
Duplicate identifier 'it'.
Duplicate identifier 'define'.
Duplicate identifier 'require'.

Jika paket global tidak diperlukan, Anda dapat menentukan folder kosong di opsi "tipe" di tsconfig.json

/ jsconfig.json

:

// src/tsconfig.json
{
   "compilerOptions": {
       // ...

       // Don't automatically include anything.
       // Only include `@types` packages that we need to import.
       "types" : []
   },
   "files": ["foo.ts"]
}

Jika Anda membutuhkan paket global, tambahkan ke lapangan types

.

// tests/tsconfig.json
{
   "compilerOptions": {
       // ...

       // Only include `@types/node` and `@types/mocha`.
       "types" : ["node", "mocha"]
   },
   "files": ["foo.test.ts"]
}

3.3. Pembuatan proyek tambahan

Bendera --incremental

memungkinkan TypeScript untuk menyimpan keadaan terkompilasi terakhir ke sebuah file .tsbuildinfo

. Ini digunakan untuk menentukan set minimum file yang dapat diperiksa ulang / ditimpa sejak dijalankan terakhir kali, seperti mode --watch

di TypeScript.

Pembuatan inkremental diaktifkan secara default saat menggunakan tanda composite

referensi lintas proyek, tetapi juga dapat mempercepat proyek lain.

3.4. Melewati validasi .d.ts

Secara default, TypeScript akan memeriksa ulang semua .d.ts

file dalam sebuah proyek untuk menemukan masalah dan inkonsistensi. Tetapi ini biasanya tidak diperlukan. Lebih sering daripada tidak, file-file ini sudah diketahui berfungsi: metode untuk memperluas tipe telah diperiksa, tetapi deklarasi penting masih akan diperiksa.

TypeScript memungkinkan sebuah bendera untuk skipDefaultLibCheck

melewati pemeriksaan tipe dalam .d.ts

file yang disediakan (misalnya lib.d.ts

).

Anda juga dapat mengaktifkan bendera skipLibCheck

untuk melewati pemeriksaan semua .d.ts

file dalam kompilasi.

Kedua opsi ini sering kali menyembunyikan kesalahan konfigurasi dan konflik .d.ts

file, jadi disarankan untuk menggunakannya hanya untuk mempercepat build.

3.5. Pemeriksaan variadic lebih cepat

Daftar anjing atau hewan? Dapat Anda memimpin List<Dg>

ke List<Animls>

? Cara mudah untuk menemukan jawabannya adalah secara struktural membandingkan jenis, elemen dengan elemen. Sayangnya, solusi ini bisa sangat mahal. Tetapi jika kita cukup tahu tentang List<>

, maka kita dapat mengurangi cek tugas untuk menentukan apakah itu diperbolehkan untuk merujuk Dog

ke Animal

(yaitu, tanpa memeriksa setiap elemen List<>

). Secara khusus, kita perlu mengetahui variabilitas tipe parameter T

. Kompilator hanya dapat memanfaatkan optimalisasi saat flag aktif strictFunctionTypes

(jika tidak maka akan menggunakan pemeriksaan struktural yang lebih lambat tetapi lebih lunak). Oleh karena itu, direkomendasikan untuk membangun dengan flag --strictFunctionTypes

(yang diaktifkan secara default di bawah --strict

).

4. Menyiapkan alat perakitan lainnya

TypeScript sering dikompilasi dengan alat bangunan lain, terutama saat membangun aplikasi web yang dapat menggunakan bundler. Kami hanya dapat menawarkan sedikit ide, tetapi secara umum pendekatan ini dapat digeneralisasikan.

Selain bagian ini, pastikan untuk membaca tentang kinerja alat pilihan Anda, misalnya:

Bagian ts-loader di artikel Faster Builds .
Bagian pemuat skrip mengagumkan di artikel Masalah Kinerja .

4.1. Pemeriksaan tipe simultan

Pemeriksaan jenis biasanya memerlukan informasi dari file lain dan relatif mahal dibandingkan dengan langkah lain seperti mengubah / menulis kode. Karena pemeriksaan jenis bisa sangat memakan waktu, hal itu dapat memengaruhi siklus pengembangan internal. Artinya, siklus edit-compile-run akan menjadi lebih lama, yang tidak menyenangkan.

Oleh karena itu, banyak alat build dapat memeriksa jenis dalam proses terpisah, tanpa memblokir pembuatan file. Meskipun dalam kasus ini, kode yang salah dapat dijalankan sebelum TypeScript melaporkan kesalahan dalam alat build Anda. Lebih sering daripada tidak, Anda akan melihat kesalahan di editor terlebih dahulu dan tidak akan menunggu kode dijalankan.

Contohnya adalah fork-ts-checker-webpack-plugin untuk Webpack, atau yang serupaawesome-typescript-loader .

4.2. Pembuatan file terisolasi

Secara default, membuat file di TypeScript memerlukan informasi semantik yang mungkin tidak bersifat lokal ke file. Ini diperlukan untuk memahami bagaimana fitur disukai const enum

dan dihasilkan namespace

. Tetapi terkadang pembuatan menjadi lebih lambat karena kebutuhan untuk memeriksa file lain untuk menghasilkan hasil untuk file yang berubah-ubah.

Kami jarang membutuhkan fitur yang membutuhkan informasi non-lokal. Reguler enum

dapat digunakan sebagai gantinya const enum

, dan modul dapat digunakan sebagai gantinya namespace

. Oleh karena itu, TypeScript memiliki tanda isolatedModules

untuk menampilkan kesalahan pada fitur yang memerlukan informasi non-lokal. Dengan tanda ini, Anda dapat dengan aman menggunakan alat yang menggunakan API TypeScript seperti transpileModule

atau kompiler alternatif seperti Babel.

Kode ini tidak akan berfungsi dengan benar pada waktu proses dengan konversi file terisolasi karena nilainya harus sebaris const enum

. Untungnya, dia akan isolatedModules

memperingatkan kita sebelumnya.

// ./src/fileA.ts

export declare const enum E {
    A = 0,
    B = 1,
}

// ./src/fileB.ts

import { E } from "./fileA";

console.log(E.A);
//          ~
// error: Cannot access ambient const enums when the '--isolatedModules' flag is provided.

Ingat: isolatedModules

tidak secara otomatis mempercepat pembuatan kode. Ini hanya memperingatkan tentang penggunaan fitur yang mungkin tidak didukung. Anda perlu membuat modul secara terpisah di berbagai alat build dan API.

Anda dapat membuat file secara terpisah menggunakan alat berikut:

The ts-loader memiliki bendera transpileOnly , yang menyediakan diisolasi membuat file dengan menggunakan transpileModule

.
awesome-typescript-loader transpileOnly, transpileModule

.
API transpileModule TypeScript .
awesome-typescript-loader useBabel.
babel-loader ( ).
gulp-typescript isolatedModules

.
rollup-plugin-typescript .
ts-jest [ isolatedModules

true

].
ts-node dapat menentukan opsi "transpileOnly" di kolom "ts-node" dari file tsconfig.json dan juga memiliki tanda --transpile-only .

5. Penyelidikan masalah

Ada berbagai cara untuk mencari tahu mengapa ada yang tidak beres.

5.1. Nonaktifkan plugin editor

Plugin dapat memengaruhi cara kerja editor. Coba nonaktifkan mereka (terutama yang terkait dengan JavaScript / TypeScript) dan lihat apakah kinerja dan daya tanggapnya meningkat.

Beberapa editor memiliki rekomendasi kinerja mereka sendiri, bacalah. Misalnya, Visual Studio Code memiliki halaman tips terpisah .

5.2. extendedDiagnostics

Anda dapat menjalankan TypeScript dengan --extendedDiagnostics

untuk melihat di mana waktu kompiler dihabiskan:

Files:                         6
Lines:                     24906
Nodes:                    112200
Identifiers:               41097
Symbols:                   27972
Types:                      8298
Memory used:              77984K
Assignability cache size:  33123
Identity cache size:           2
Subtype cache size:            0
I/O Read time:             0.01s
Parse time:                0.44s
Program time:              0.45s
Bind time:                 0.21s
Check time:                1.07s
transformTime time:        0.01s
commentTime time:          0.00s
I/O Write time:            0.00s
printTime time:            0.01s
Emit time:                 0.01s
Total time:                1.75s

Harap dicatat bahwa Total time

ini tidak akan menjadi jumlah dari semua biaya waktu yang terdaftar, karena beberapa di antaranya tumpang tindih, dan beberapa tidak diukur sama sekali.

Informasi paling relevan untuk sebagian besar pengguna:

Bidang	Nilai
`Files`	Jumlah file yang disertakan dalam program (jenis file apa yang dapat Anda lihat menggunakan `--listFiles` ).
`I/O Read time`	Waktu yang dihabiskan untuk membaca dari sistem file. Ini termasuk membaca folder dari `include` .
`Parse time`	Waktu yang dihabiskan untuk memindai dan mengurai program.
`Program time`	Total waktu untuk membaca dari sistem file, memindai dan mem-parsing program, serta kalkulasi grafik lainnya. Tahapan ini digabungkan di sini karena harus diaktifkan dan dimuat segera setelah ditambahkan melalui `import` dan `export` .
`Bind time`	Waktu yang dihabiskan untuk menyusun berbagai informasi semantik yang bersifat lokal ke file tertentu.
`Check time`	Waktu yang dihabiskan untuk memeriksa jenis dalam program.
`transformTime time`	Waktu yang dihabiskan untuk menulis ulang TypeScript AST (struktur pohon yang mewakili file sumber) ke dalam formulir yang berfungsi di lingkungan waktu proses lama.
`commentTime`	Waktu yang dihabiskan untuk mengevaluasi komentar dalam file yang dibuat.
`I/O Write time`	Waktu yang dihabiskan untuk menulis dan memperbarui file di disk.
`printTime`	Waktu yang dibutuhkan untuk menghitung representasi string dari file yang dihasilkan dan menyimpannya ke disk.

Dengan masukan ini, apa yang mungkin Anda butuhkan:

Apakah jumlah file / baris kode kira-kira sesuai dengan jumlah file dalam proyek? Jika tidak, coba gunakan --listFiles

.
Apakah nilai Program time

atau I/O Read time

terlihat besar? Periksa apakah pengaturan sudah benar include

/exclude

Sepertinya ada yang salah dengan pengaturan waktu lainnya? Anda dapat mengisi laporan masalah! Apa yang akan membantu Anda mendiagnosis:

Mulailah dengan emitDeclarationOnly

jika nilainya printTime

tinggi.
Instruksi Pelaporan Masalah Kinerja Kompilator

5.3. showConfig

Tidak selalu jelas dengan pengaturan apa kompilasi dilakukan saat startup tsc

, terutama mengingat tsconfig.jsons

file konfigurasi lain dapat diperluas. showConfig

dapat menjelaskan apa yang akan dihitungnya tsc

.

tsc --showConfig

# or to select a specific config file...

tsc --showConfig -p tsconfig.json

5.4. traceResolution

Menjalankan dengan traceResolution

akan memberi tahu Anda mengapa file ditambahkan ke kompilasi. Datanya cukup luas, jadi Anda bisa menyimpan hasilnya ke file:

tsc --traceResolution > resolution.txt

Jika Anda menemukan file yang seharusnya tidak ada di sana, Anda dapat memperbaiki daftar include

/ exclude

dalam file tersebut tsconfig.json

, atau menyesuaikan pengaturan seperti types

, typeRoots

atau paths

.

5.5. Menjalankan satu tsc

Pengguna sering mengalami kinerja yang buruk dengan alat pembangunan pihak ketiga seperti Gulp, Rollup, Webpack, dll. Menjalankan tsc --extendedDiagnostics

untuk menemukan perbedaan utama antara TypeScript dan alat pihak ketiga dapat menunjukkan kesalahan dalam konfigurasi eksternal atau ketidakefisienan.

Apa yang perlu Anda tanyakan pada diri sendiri:

Apakah ada perbedaan besar dalam waktu pembuatan tsc

dengan alat terintegrasi TypeScript?
Jika alat pihak ketiga memiliki alat diagnostik, apakah solusinya berbeda antara TypeScript dan alat pihak ketiga?
Apakah alat tersebut memiliki konfigurasinya sendiri yang mungkin menyebabkan kinerja yang buruk?
Apakah alat tersebut memiliki konfigurasi untuk mengintegrasikannya dengan TypeScript yang dapat menyebabkan kinerja yang buruk (seperti opsi untuk ts-loader)?

5.6. Memperbarui dependensi

Terkadang file yang kompleks secara komputasi dapat memengaruhi pemeriksaan tipe dalam TypeScript .d.ts

. Jarang, tapi itu terjadi. Ini biasanya diselesaikan dengan meningkatkan ke versi TypeScript yang lebih baru (lebih efisien) atau versi paket yang lebih baru @types

(yang dapat membalikkan regresi).

6. Masalah yang sering terjadi

Saat menghadapi kesulitan, Anda pasti ingin belajar tentang solusi untuk masalah umum. Jika berikut ini tidak membantu, Anda dapat melaporkan masalah tersebut .

6.1. Sertakan dan kecualikan dikonfigurasi dengan tidak benar

Seperti disebutkan, include

/ options exclude

dapat disalahgunakan.

Masalah	Sebab	Koreksi
`node_modules` tidak sengaja ditambahkan dari subfolder yang lebih dalam.	Tidak dikonfigurasi `exclude`	`"exclude": ["/node_modules", "/.*/"]`
`node_modules` tidak sengaja ditambahkan dari subfolder yang lebih dalam.	`"exclude": ["node_modules"]`	`"exclude": ["/node_modules", "/.*/"]`
File tersembunyi dengan titik ditambahkan secara acak (misalnya `.git` ).	`"exclude": ["**/node_modules"]`	`"exclude": ["/node_modules", "/.*/"]`
Menambahkan file yang tidak terduga.	Tidak dikonfigurasi `include`	`"include": ["src"]`

7. Melengkapi Laporan Masalah

Jika proyek Anda sudah dikonfigurasi dengan benar dan optimal, maka Anda dapat mengisi laporan masalah .

Laporan yang bagus berisi deskripsi masalah yang mudah diikuti. Artinya, ini berisi basis kode dari beberapa file yang dapat dengan mudah dikloning melalui Git. Dalam kasus ini, tidak diperlukan integrasi eksternal dengan alat perakitan, alat tersebut dapat dipanggil tsc

, atau Anda dapat menggunakan kode kotak pasir yang menggunakan API TypeScript. Anda tidak dapat memprioritaskan basis kode yang memerlukan panggilan dan pengaturan yang rumit.

Ya, ini tidak selalu mudah untuk dicapai. Terutama karena sulitnya mengisolasi sumber masalah dalam basis kode, dan ada juga pertimbangan perlindungan kekayaan intelektual. Dalam beberapa kasus, Anda dapat mengirimkan NDA kepada kami jika menurut Anda masalah tersebut sangat penting.

Terlepas dari reproduktifitas masalah, saat menyelesaikan laporan, ikuti tip berikut, mereka akan membantu kami dalam menemukan solusi.

7.1. Laporan Masalah Kinerja Kompiler

Terkadang, masalah kinerja terjadi selama pembuatan dan pengeditan. Maka masuk akal untuk fokus pada compiler TypeScript.

Pertama, gunakan TypeScript versi "nightly" untuk memastikan Anda tidak mengalami masalah yang diperbaiki:

npm install --save-dev typescript@next

# or

yarn add typescript@next --dev

Deskripsi masalah kinerja harus mencakup:

Versi TypeScript ( npx tsc -v

atau yarn tsc -v

) yang diinstal .
Versi Node tempat TypeScript ( node -v

) dijalankan .
Hasil dari menjalankan dengan opsi extendedDiagnostics

( tsc --extendedDiagnostics -p tsconfig.json

).
Idealnya, proyek itu sendiri diperlukan untuk mendemonstrasikan masalah yang dihadapi.
Log profiler penyusun (file isolate-*-*-*.log

dan *.cpuprofile

).

Pembuatan profil kompilator

Penting untuk memberi kami pelacakan diagnostik dengan menjalankan Node.js v10 + dengan flag --trace-ic

dan TypeScript dengan flag --generateCpuProfile

:

node --trace-ic ./node_modules/typescript/lib/tsc.js --generateCpuProfile profile.cpuprofile -p tsconfig.json

Ini ./node_modules/typescript/lib/tsc.js

dapat diganti dengan jalur mana pun versi compiler TypeScript Anda diinstal. Dan sebaliknya tsconfig.json

bisa berupa file konfigurasi TypeScript. Sebagai gantinya profile.cpuprofile

- file keluaran pilihan Anda.

Dua file akan dibuat:

--trace-ic

akan menyimpan data ke file tampilan isolate-*-*-*.log

(misalnya isolate-00000176DB2DF130-17676-v8.log

).
--generateCpuProfile

akan menyimpan data ke file dengan nama pilihan Anda. Dalam contoh di atas, ini profile.cpuprofile

.

Catatan : File-file ini mungkin berisi informasi dari ruang kerja Anda, termasuk jalur dan kode sumber. Kedua file tersebut dibuat dalam teks biasa, dan Anda dapat mengeditnya sebelum melampirkannya ke laporan Github (misalnya, dengan menghapus jalur yang dapat mengungkapkan informasi sensitif).

Tetapi jika Anda ragu untuk menempatkannya di Github, kirimkan surat kepada kami, dan Anda dapat mengirimkan informasi secara pribadi.

7.2. Laporkan Masalah Kinerja Editor

Ada banyak alasan untuk kinerja pengeditan yang buruk. Dan tim TypeScript hanya dapat mempengaruhi kinerja layanan bahasa JavaScript / TypeScript, serta integrasi antara layanan bahasa dan editor tertentu (seperti Visual Studio, Visual Studio Code, Visual Studio untuk Mac, dan Sublime Text). Pastikan semua plugin pihak ketiga dimatikan di editor Anda. Ini akan memverifikasi bahwa masalah terkait dengan TypeScript itu sendiri.

Masalah kinerja editor sedikit lebih kompleks, tetapi ide yang sama berlaku: basis kode minimal yang dikloning dengan masalah yang dapat direproduksi sangat ideal. Dan dalam beberapa kasus, kami dapat menandatangani NDA untuk menyelidiki dan mengisolasi masalah.

Menambahkan data daritsc --extendedDiagnostics

, tetapi lebih baik lagi jika ada jejak TSServer.

Mendapatkan log TSServer dalam Visual Studio Code

Buka bilah perintah, lalu:
Atur opsinya «typescript.tsserver.log»: «verbose»,

.
Mulai ulang VS Code dan ulangi masalahnya.
Di VS Code, jalankan perintah TypeScript: Open TS Server log

.
File harus terbuka tsserver.log

.

Catatan : Log TSServer mungkin berisi informasi dari ruang kerja Anda, termasuk jalur dan kode sumber. Jika Anda ragu untuk meletakkannya di Github, kirimkan surat kepada kami dan Anda dapat mengirimkan informasi secara pribadi.

Performa TypeScript