TypeScript 7 nhanh hơn tới 10 lần: Có nên nâng cấp ngay không?

TypeScript 7 đang thu hút sự chú ý lớn trong cộng đồng lập trình JavaScript nhờ một thay đổi mang tính nền tảng: trình biên dịch và dịch vụ ngôn ngữ được chuyển sang triển khai bằng Go. Theo các số liệu được Microsoft công bố, thời gian biên dịch ở nhiều dự án lớn có thể giảm từ 8 đến 12 lần, đồng thời mức sử dụng bộ nhớ tổng thể cũng được cải thiện.

Những con số này rất ấn tượng. Tuy nhiên, tốc độ biên dịch không phải là yếu tố duy nhất cần cân nhắc trước khi nâng cấp TypeScript. Một dự án thực tế còn phụ thuộc vào framework, trình tạo declaration, project references, hệ thống lint, plugin IDE, công cụ build và nhiều gói tích hợp khác.

Vì vậy, câu hỏi phù hợp không chỉ là “TypeScript 7 có nhanh hơn không?”, mà là:

“TypeScript 7 giúp dự án của tôi tiết kiệm bao nhiêu thời gian, và quá trình nâng cấp có làm ảnh hưởng đến hệ sinh thái công cụ hiện tại hay không?”

Bạn không cần dành cả tuần để tìm câu trả lời. Chỉ cần tạo một nhánh thử nghiệm, ghi lại các phép đo hiện tại, cài đặt TypeScript 7 và chạy lại cùng một bộ kiểm tra.

TypeScript 7 có gì đặc biệt?

Thông thường, một phiên bản TypeScript mới sẽ bổ sung cú pháp, cải thiện khả năng kiểm tra kiểu hoặc sửa lỗi trong trình biên dịch hiện tại. TypeScript 7 khác biệt vì đây không chỉ là bản cập nhật tính năng thông thường.

Microsoft đang thay thế trình biên dịch và language service dựa trên JavaScript bằng một triển khai native viết bằng Go. Kiến trúc mới hướng đến:

• Tăng tốc quá trình kiểm tra kiểu và biên dịch.
• Tận dụng khả năng xử lý song song và bộ nhớ dùng chung.
• Giảm thời gian phản hồi trong trình soạn thảo mã nguồn.
• Cải thiện hiệu suất ở các monorepo và codebase lớn.
• Giảm thời gian chờ khi chạy build nhiều lần trong ngày.

Theo các benchmark do Microsoft công bố, một số dự án mã nguồn lớn có mức cải thiện đáng kể:

• VS Code: từ khoảng 125,7 giây xuống còn 10,6 giây.
• Sentry: từ khoảng 139,8 giây xuống còn 15,7 giây.
• Playwright: từ khoảng 12,8 giây xuống còn 1,47 giây.
• tldraw: từ khoảng 11,2 giây xuống còn 1,46 giây.

Những số liệu này cho thấy tiềm năng rất lớn, nhưng không nên hiểu đó là kết quả đảm bảo cho mọi dự án. Một ứng dụng nhỏ có thể dành phần lớn thời gian cho bundling, chạy test, tối ưu tài nguyên hoặc xử lý framework. Trong trường hợp đó, tốc độ của riêng tsc chỉ ảnh hưởng một phần đến tổng thời gian build.

Ai sẽ hưởng lợi nhiều nhất từ TypeScript 7?

TypeScript 7 đặc biệt đáng thử nếu dự án của bạn thuộc một trong các nhóm sau:

• Monorepo có nhiều package và hàng nghìn tệp TypeScript.
• Dự án sử dụng project references phức tạp.
• Quá trình kiểm tra kiểu hiện mất nhiều phút.
• IDE thường xuyên mất thời gian tải workspace hoặc cập nhật lỗi.
• Nhóm phát triển phải chạy lại type-check nhiều lần mỗi ngày.
• CI/CD dành phần lớn thời gian cho bước biên dịch TypeScript.
• Dự án có nhiều file declaration hoặc cần tạo thư viện phân phối.

Ngược lại, lợi ích có thể không quá rõ rệt nếu ứng dụng chỉ có vài chục tệp mã nguồn hoặc thời gian build chủ yếu nằm ở các bước ngoài TypeScript như chạy end-to-end test, đóng gói asset và triển khai container.

Đo hiệu suất TypeScript hiện tại trước khi nâng cấp

Đừng bắt đầu bằng việc cài phiên bản mới ngay lập tức. Trước hết, hãy ghi lại trạng thái hiện tại của dự án. Đây là bước quan trọng để tránh đánh giá cảm tính.

Kiểm tra phiên bản TypeScript đang sử dụng

Chạy lệnh sau trong thư mục dự án:

npx tsc --version

Lệnh này giúp xác định phiên bản TypeScript được gọi từ dependency của dự án. Không nên chỉ kiểm tra phiên bản TypeScript cài đặt toàn cục vì nó có thể khác với phiên bản được sử dụng trong CI hoặc trong file lock.

Đo thời gian kiểm tra kiểu

Với dự án thông thường, bạn có thể sử dụng:

time npx tsc --noEmit

Tùy chọn --noEmit yêu cầu TypeScript kiểm tra mã nguồn nhưng không tạo ra file JavaScript. Đây thường là phép đo phù hợp để đánh giá riêng hiệu suất type-checking.

Nếu dự án sử dụng project references, hãy kiểm tra bằng:

time npx tsc --build --force

Tùy chọn --force giúp buộc xây dựng lại các project references, phù hợp khi cần so sánh một lần build đầy đủ.

Đo toàn bộ quy trình phát triển

Type-check không phải là công việc duy nhất trong một dự án TypeScript. Hãy chạy thêm các lệnh đại diện cho quy trình thực tế:

npm run lint
npm test
npm run build

Nếu dự án có các script riêng, bạn cũng nên đưa chúng vào phép đo:

npm run typecheck
npm run test:unit
npm run test:e2e
npm run build:production
npm run declarations

Hãy chạy mỗi lệnh nhiều lần trong điều kiện tương tự. Một lần chạy đầu tiên thường bị ảnh hưởng bởi cache, trạng thái của ổ đĩa, mức sử dụng CPU hoặc các tiến trình nền. Không nên so sánh một lần chạy lạnh với một lần chạy nóng rồi kết luận rằng TypeScript 7 nhanh hơn.

Mẫu ghi nhận kết quả

Phiên bản TypeScript hiện tại:
Type-check lần đầu:
Type-check lần thứ hai:
Build production:
Thời gian chạy test:
Tạo declaration:
Thời gian tải IDE:

Với trình soạn thảo, bạn có thể đo tương đối bằng cách mở cùng một workspace, sau đó quan sát thời gian cần thiết để lỗi kiểu, gợi ý mã, auto-import và tính năng tìm tham chiếu hoạt động ổn định.

Thử TypeScript 7 trong một nhánh riêng

Không nên nâng cấp trực tiếp trên nhánh chính. Hãy tạo một nhánh thử nghiệm để có thể quay lại trạng thái trước đó bất cứ lúc nào:

git switch -c test/typescript-7

Sau đó cài đặt phiên bản TypeScript 7 theo hướng dẫn chính thức của dự án:

npm install --save-dev typescript@latest

Tiếp tục xác nhận rằng lệnh cục bộ đang sử dụng đúng phiên bản mới:

npx tsc --version

Việc kiểm tra này rất cần thiết vì máy tính có thể đang có một phiên bản TypeScript toàn cục khác với phiên bản được khai báo trong package.json.

Chạy lại chính xác các phép đo cũ

Sau khi cài đặt TypeScript 7, hãy chạy lại cùng các lệnh đã sử dụng trước đó:

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

Nếu dự án có các quy trình đặc thù, đừng bỏ qua chúng. Hãy kiểm tra thêm:

• Biên dịch bằng project references.
• Tạo file .d.ts.
• Đóng gói thư viện.
• API Extractor hoặc các công cụ tương tự.
• Code generation dựa trên compiler.
• Kiểm tra template của Angular, Vue hoặc framework khác.
• Biên dịch MDX và các ngôn ngữ nhúng.
• Build production thực tế được sử dụng trong CI/CD.

Một lệnh npx tsc --noEmit chạy thành công là điều kiện cần, nhưng chưa đủ để kết luận rằng toàn bộ quá trình nâng cấp đã an toàn.

So sánh TypeScript 6 và TypeScript 7 một cách chính xác

Hãy ghi lại kết quả trước và sau khi nâng cấp trong một bảng đơn giản:

Ngoài con số thời gian, hãy chú ý đến chất lượng đầu ra và trải nghiệm phát triển:

• IDE có tải workspace nhanh hơn không?
• Auto-completion có đưa ra kết quả đầy đủ không?
• Tính năng tìm tất cả tham chiếu có bỏ sót symbol không?
• Đổi tên một symbol có cập nhật chính xác trên nhiều file không?
• Quick fix có tự động thêm import như trước không?
• File declaration có thay đổi ngoài dự kiến không?
• Framework build có thực sự sử dụng TypeScript 7 không?
• Lint có cảnh báo peer dependency không tương thích không?
• CI có chạy cùng phiên bản với máy local không?

Ranh giới tương thích quan trọng: Compiler API

Một trong những điểm cần đặc biệt lưu ý là TypeScript 7.0 chưa cung cấp một programmatic compiler API ổn định theo cách mà nhiều công cụ trước đây vẫn sử dụng.

Điều này có thể ảnh hưởng đến các công cụ không chỉ gọi lệnh tsc, mà còn import trực tiếp TypeScript như một thư viện. Ví dụ gồm:

• Custom transformer.
• Compiler plugin.
• Công cụ tạo declaration.
• Framework tích hợp sâu với TypeScript.
• Công cụ xử lý ngôn ngữ nhúng.
• Hệ thống sinh mã dựa trên compiler API.
• Plugin editor phụ thuộc vào language service cũ.

Trong một số trường hợp, Microsoft cung cấp package tương thích @typescript/typescript6 để những công cụ cũ vẫn có thể sử dụng API quen thuộc, trong khi TypeScript 7 đảm nhận vai trò biên dịch native.

Một cấu hình side-by-side có thể có dạng:

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

Tuy nhiên, không nên sao chép cấu hình này một cách máy móc. Trước tiên hãy xác định công cụ nào trong dự án thực sự cần compiler API cũ. Sau đó, đọc tài liệu migration mới nhất của công cụ đó để chọn phương án phù hợp.

Những loại dự án cần kiểm tra kỹ hơn

Bạn nên dành thêm thời gian kiểm thử nếu dự án đang sử dụng một hoặc nhiều thành phần sau:

• Custom TypeScript transformer: có thể phụ thuộc vào cấu trúc nội bộ của compiler.
• Framework template checker: quá trình kiểm tra template có thể có yêu cầu phiên bản riêng.
• MDX hoặc embedded language: có thể cần plugin language service tương thích.
• Declaration bundler: cần kiểm tra sự thay đổi trong file API công khai.
• Code generation: cần đối chiếu file sinh ra trước và sau khi nâng cấp.
• Project references: cần kiểm tra thứ tự build và cache giữa các package.
• Editor plugin: phải xác nhận plugin hoạt động với language service mới.
• Build system khóa phiên bản TypeScript: framework có thể chỉ hỗ trợ một khoảng phiên bản nhất định.

Trong các dự án này, việc type-check thành công chỉ cho biết mã nguồn cơ bản không có lỗi. Nó không chứng minh rằng tất cả công cụ phụ trợ đã tương thích.

Kiểm tra riêng trải nghiệm trong IDE

TypeScript 7 sử dụng Language Server Protocol, giúp language service có thể được tích hợp với nhiều trình soạn thảo khác nhau. Tuy nhiên, cách kích hoạt TypeScript 7 có thể phụ thuộc vào từng IDE và phiên bản plugin.

Đừng mặc định rằng chỉ cần thay đổi dependency trong package.json là trình soạn thảo sẽ tự động dùng phiên bản mới. Hãy kiểm tra cấu hình TypeScript của IDE và thực hiện một số thao tác phổ biến.

1. Mở một file lớn có sẵn lỗi kiểu.
2. Gõ mã mới để kiểm tra tốc độ auto-completion.
3. Tìm tất cả tham chiếu của một symbol được sử dụng rộng rãi.
4. Đổi tên symbol trên nhiều file.
5. Dùng quick fix để thêm import.
6. Di chuyển giữa các package trong monorepo.
7. Khởi động lại IDE và quan sát thời gian tải project.
8. Kiểm tra lỗi có được cập nhật đầy đủ sau khi chỉnh sửa mã nguồn không.

Đối với nhiều lập trình viên, cải thiện trong IDE có giá trị hơn vài giây tiết kiệm được ở production build. Một vòng lặp phản hồi ngắn hơn sẽ ảnh hưởng trực tiếp đến năng suất mỗi ngày.

Đừng quên kiểm tra declaration output

Nếu dự án xuất bản thư viện, file declaration là một phần của API công khai. Một thay đổi nhỏ trong .d.ts có thể ảnh hưởng đến người dùng cuối, ngay cả khi mã nguồn của chính dự án vẫn biên dịch thành công.

Sau khi nâng cấp, hãy đối chiếu:

• Số lượng file declaration được tạo ra.
• Cấu trúc type được export.
• Các generic và conditional type.
• Kiểu trả về của API công khai.
• Thứ tự hoặc định dạng file nếu dự án có snapshot.
• Kết quả của API Extractor hoặc declaration bundler.

Nếu declaration thay đổi, hãy xác định đó là thay đổi có chủ đích hay chỉ là khác biệt do trình biên dịch mới tạo ra. Không nên phát hành phiên bản thư viện mới trước khi kiểm tra kỹ API tương thích.

Kiểm tra framework, lint và hệ thống CI

TypeScript thường không hoạt động độc lập. Nhiều dự án sử dụng thêm framework compiler, bundler, linter, test runner và hệ thống build riêng.

Hãy kiểm tra các điểm sau:

• Framework có công bố hỗ trợ TypeScript 7 chưa?
• Bundler có đọc đúng cấu hình TypeScript không?
• ESLint parser có tương thích với phiên bản mới không?
• Plugin lint có yêu cầu peer dependency cụ thể không?
• Test runner có thể biên dịch mã nguồn bình thường không?
• Docker image hoặc CI runner có cài đúng dependency không?
• File lock có được cập nhật và commit đầy đủ không?
• Phiên bản Node.js có đáp ứng yêu cầu của hệ sinh thái mới không?

Đặc biệt, hãy xác nhận môi trường CI đang sử dụng đúng phiên bản TypeScript. Một lỗi phổ biến là máy local dùng TypeScript 7 nhưng CI lại cài dependency từ lockfile cũ hoặc gọi một binary toàn cục khác.

Khi nào nên giữ TypeScript 7?

Bạn có thể cân nhắc giữ bản nâng cấp nếu tất cả điều kiện sau đều được đáp ứng:

• Type-check và build hoàn thành thành công.
• Thời gian biên dịch giảm rõ rệt trong điều kiện thực tế.
• Unit test và integration test vẫn đạt.
• Declaration output không thay đổi ngoài dự kiến.
• Framework và bundler hoạt động ổn định.
• IDE vẫn cung cấp đầy đủ tính năng cần thiết.
• Các plugin và công cụ phụ trợ không gặp lỗi tương thích.
• CI sử dụng đúng phiên bản TypeScript đã kiểm thử.
• Lợi ích hiệu suất đủ lớn để bù đắp chi phí migration.

Không nhất thiết phải đạt mức tăng tốc giống các benchmark của Microsoft. Nếu dự án giảm được đáng kể thời gian chờ trong IDE hoặc CI, việc nâng cấp vẫn có thể mang lại giá trị lớn.

Khi nào nên tạm thời quay lại phiên bản cũ?

Việc trì hoãn nâng cấp là hợp lý nếu bạn gặp một trong các tình huống sau:

• Một công cụ quan trọng vẫn phụ thuộc vào compiler API cũ.
• File sinh ra thay đổi nhưng chưa xác định được nguyên nhân.
• Framework chưa công bố hỗ trợ phiên bản mới.
• IDE hoặc plugin chính chưa hoạt động đầy đủ.
• CI và môi trường local cho kết quả khác nhau.
• Declaration công khai bị thay đổi ngoài mong muốn.
• Mức tăng tốc không đủ lớn so với công sức xử lý tương thích.

Quay lại không có nghĩa là nâng cấp thất bại. Một kết luận “chưa phù hợp ở thời điểm hiện tại” vẫn là kết quả có giá trị, miễn là bạn đã xác định rõ nguyên nhân và theo dõi các bản cập nhật tiếp theo.

Hoàn tác nhánh thử nghiệm

git switch -
git branch -D test/typescript-7

Nếu chưa muốn xóa nhánh, bạn có thể giữ lại để theo dõi tiến độ tương thích của các công cụ đang gặp vấn đề.

Checklist nâng cấp TypeScript 7 trong khoảng 10 phút

• Ghi lại phiên bản TypeScript hiện tại.
• Đo lệnh type-check ít nhất hai lần.
• Chạy lint, test và production build.
• Tạo một nhánh nâng cấp riêng.
• Cài TypeScript 7 trong phạm vi dự án.
• Xác minh binary đang được sử dụng bằng npx tsc --version.
• Chạy lại toàn bộ phép đo trước đó.
• Kiểm tra trải nghiệm trong IDE.
• Đối chiếu declaration output.
• Kiểm tra project references và code generation.
• Xác định công cụ nào import TypeScript bằng API lập trình.
• Xác nhận CI dùng đúng phiên bản.
• Chỉ giữ nâng cấp khi hiệu suất và tính ổn định đều được đảm bảo.

Kết luận: Có nên nâng cấp TypeScript 7 ngay không?

TypeScript 7 là một bản nâng cấp rất đáng chú ý bởi nó thay đổi nền tảng triển khai của compiler và language service, thay vì chỉ tối ưu một vài thành phần nhỏ. Các benchmark công khai cho thấy tiềm năng tăng tốc lớn, đặc biệt trong những codebase lớn, monorepo và quy trình phát triển có tần suất type-check cao.

Tuy nhiên, không nên nâng cấp chỉ dựa trên tiêu đề “nhanh hơn tới 10 lần”. Hiệu quả thực tế còn phụ thuộc vào tỷ trọng thời gian mà TypeScript chiếm trong quy trình build, cũng như mức độ phụ thuộc của dự án vào compiler API và các plugin bên ngoài.

Quy trình an toàn nhất là:

Đo hiệu suất hiện tại
          ↓
Tạo nhánh thử nghiệm
          ↓
Cài đặt TypeScript 7
          ↓
Chạy lại cùng bộ kiểm tra
          ↓
Kiểm tra IDE và công cụ phụ trợ
          ↓
Giữ bản nâng cấp hoặc ghi nhận lý do trì hoãn

Nếu dự án của bạn có quy mô lớn hoặc đang gặp vấn đề về thời gian phản hồi, TypeScript 7 rất đáng để thử nghiệm ngay. Nếu dự án phụ thuộc nhiều vào framework, plugin hoặc compiler API chưa tương thích, hãy nâng cấp có kiểm soát và chờ hướng dẫn chính thức từ các nhà cung cấp công cụ.

Để kết quả benchmark có ý nghĩa, bạn có thể ghi lại bốn thông tin cơ bản:

• Quy mô tương đối của dự án.
• Phiên bản TypeScript trước khi nâng cấp.
• Thời gian type-check trước đó.
• Thời gian type-check sau khi chuyển sang TypeScript 7.

Hai dự án cùng sử dụng TypeScript nhưng có thể cho kết quả hoàn toàn khác nhau. Một ứng dụng nhỏ, một thư viện công khai và một monorepo hàng nghìn package sẽ có nhu cầu và giới hạn tương thích rất khác biệt.

Nguồn tham khảo chính thức

• Microsoft TypeScript Blog: Announcing TypeScript 7.0
• Microsoft TypeScript Blog: Progress on TypeScript 7
• Trang chủ chính thức của TypeScript
• Kho mã nguồn TypeScript trên GitHub