Công bố TypeScript 7.0

 (devblogs.microsoft.com)
4 điểm bởi GN⁺ 2 giờ trước | 2 bình luận | Chia sẻ qua WhatsApp
  • TypeScript 7.0 là bản phát hành đã chuyển toolchain sang mã native dựa trên Go, mang lại tốc độ nhanh hơn 8~12 lần trong các lần build toàn bộ của dự án lớn
  • tsc mới vẫn được cài qua gói typescript trên npm như trước, còn hỗ trợ cho trình soạn thảo hoạt động qua language server dựa trên LSP trên VS Code, Visual Studio, WebStorm và các công cụ khác
  • Thời gian build đã giảm mạnh trên các codebase như vscode, sentry, bluesky, playwright, tldraw, và trong một số môi trường, tổng mức dùng bộ nhớ cũng giảm xuống
  • TypeScript 7.0 hiện vẫn chưa có API lập trình ổn định, nên các công cụ nhúng TypeScript như typescript-eslint, Vue, MDX, Astro, Svelte, kiểm tra kiểu template của Angular cần chạy song song với TypeScript 6.0
  • Có các giá trị mặc định mới và tùy chọn đã bị loại bỏ, nên việc áp dụng trước các thay đổi của TypeScript 6.0 sẽ giúp quá trình chuyển đổi thuận lợi hơn; TypeScript 7.1 dự kiến sẽ cung cấp API mới

TypeScript native dựa trên Go

  • TypeScript 7.0 là bản port native của toolchain TypeScript, sử dụng codebase mới được viết bằng Go
  • Việc port được thực hiện theo hướng giữ tối đa cấu trúc và logic của codebase hiện có để đảm bảo tính nhất quán của kết quả và khả năng tương thích giữa hai compiler
  • Codebase mới cho kết quả nhanh hơn khoảng 8~12 lần trong các lần build toàn bộ nhờ tốc độ của mã native, đa luồng dựa trên bộ nhớ dùng chung và nhiều tối ưu hóa khác
  • Việc cài đặt vẫn có thể thực hiện qua npm như trước
npm install -D typescript
  • Sau khi cài đặt, có thể dùng file thực thi tsc mới trong workspace và chạy bằng npx tsc

Rút ngắn vòng phản hồi khi phát triển

  • TypeScript tham gia vào nhiều giai đoạn trong quá trình phát triển như tải trình soạn thảo, tìm tất cả tham chiếu, tự động hoàn thành, chẩn đoán, tsc, chế độ --watch và hơn thế nữa
  • TypeScript 7 giảm thời gian chờ trong toàn bộ quá trình này, giúp vòng phản hồi ngắn hơn
  • Trên codebase của VS Code, thời gian từ lúc mở file có lỗi đến khi lỗi đầu tiên xuất hiện đã giảm từ khoảng 17.5 giây xuống còn dưới 1.3 giây, nhanh hơn hơn 13 lần
  • Hỗ trợ trình soạn thảo dựa trên LSP, và language server mới tận dụng đa luồng để xử lý nhanh các yêu cầu đồng thời
  • Người dùng VS Code có thể cài tiện ích mở rộng dành riêng cho TypeScript 7, và trong vài tuần tới, bản thân VS Code cũng dự kiến sẽ tích hợp hỗ trợ TypeScript 7
  • Phiên bản mới nhất của Visual Studio sẽ tự động kích hoạt TypeScript 7 tùy theo workspace

Hiệu năng build và kết quả bộ nhớ

  • Thời gian build toàn bộ khi so sánh TypeScript 6 và 7 trên các codebase mã nguồn mở lớn như sau
Codebase TypeScript 6 TypeScript 7 Mức tăng tốc
vscode 125.7 giây 10.6 giây 11.9 lần
sentry 139.8 giây 15.7 giây 8.9 lần
bluesky 24.3 giây 2.8 giây 8.7 lần
playwright 12.8 giây 1.47 giây 8.7 lần
tldraw 11.2 giây 1.46 giây 7.7 lần
  • Trong cùng các lần build đó, TypeScript 7 nhìn chung cũng có tổng mức dùng bộ nhớ thấp hơn
Codebase TypeScript 6 TypeScript 7 Thay đổi bộ nhớ
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%

Kiểm chứng trên codebase thực tế và phản hồi từ các nhóm

  • Dự án TypeScript chạy hàng chục nghìn bài kiểm thử được tích lũy suốt hơn 10 năm trên mọi commit của nhánh main
  • Ngoài các bài kiểm thử này, TypeScript 7 còn được kiểm chứng trên codebase thực tế của các nhóm lớn cả nội bộ lẫn bên ngoài
  • Trong nội bộ Microsoft, các nhóm Loop, Office, PowerBI, Teams, Xbox đã kiểm chứng TypeScript 7
  • Bên ngoài, Bloomberg, Canva, Figma, Google, Lattice, Linear, Miro, Notion, Sentry, Slack, Vanta, Vercel, VoidZero và nhiều đơn vị khác đã thử nghiệm trên codebase của họ và gửi phản hồi
  • Language server mới giảm hơn 80% số lệnh language server thất bại và giảm hơn 60% số lần server bị crash so với TypeScript 6.0
  • Phản hồi thực tế từ các nhóm bao gồm các trường hợp sau
    • Slack cho biết thời gian merge queue đã giảm 40% với TypeScript 7, và thời gian kiểm tra kiểu trong CI giảm từ khoảng 7.5 phút xuống 1.25 phút
    • Vanta ghi nhận mức tăng tốc build lên đến 9 lần trên một trong các dự án lớn của họ
    • Nhóm Microsoft News Services tiết kiệm 400 giờ chờ build CI mỗi tháng
    • Canva cho biết thời gian để lỗi đầu tiên xuất hiện trong trình soạn thảo đã giảm từ khoảng 58 giây xuống 4.8 giây

Chạy song song với TypeScript 6.0

  • TypeScript 7.0 hiện chưa bao gồm API
  • TypeScript 7.1 dự kiến sẽ cung cấp một API mới và khác biệt
  • Trước thời điểm đó, có thể chạy song song TypeScript 6.0 và 7.0 cho các công cụ cần truy cập lập trình vào compiler
  • Gói tương thích mới @typescript/typescript6 cung cấp file thực thi tsc6 và tái xuất API của TypeScript 6.0
  • Với các công cụ như typescript-eslint trực tiếp import typescript dưới dạng peer dependency, npm alias được khuyến nghị
npm install -D typescript@npm:@typescript/typescript6
  • Để dùng đồng thời API của TypeScript 6 và tsc của TypeScript 7, có thể đặt alias như sau
{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  }
}
  • Gói @typescript/native-preview trước đây đã cung cấp các bản build nightly của codebase mới trong TypeScript 7, và từng đạt hơn 8.5 triệu lượt tải mỗi tuần
  • Trong thời gian tới, các bản build nightly sẽ được tiếp tục cung cấp qua thẻ next của gói typescript tiêu chuẩn
npm install -D typescript@next

Tùy chọn kiểm soát song song hóa

  • TypeScript 7.0 chạy song song nhiều giai đoạn như parsing, kiểm tra kiểu và emit

  • Parsing và emit dễ chạy độc lập theo từng file, nên có thể mở rộng trên codebase lớn với chi phí overhead tương đối thấp

  • Các cờ thử nghiệm mới --checkers, --builders, --singleThreaded dùng để điều chỉnh hành vi song song hóa

  • --checkers

    • TypeScript 7.0 tạo ra một số lượng cố định worker kiểm tra kiểu, và luôn chia công việc theo cùng một cách trên cùng tập tin đầu vào để cho ra kết quả nhất quán
    • Số worker kiểm tra kiểu mặc định là 4, và có thể điều chỉnh bằng --checkers
    • Kết quả trên cùng một máy khi dùng --checkers 8 như sau
    Codebase TypeScript 6 TypeScript 7 --checkers 8 Mức tăng tốc
    vscode 125.7 giây 7.51 giây 16.7 lần
    sentry 139.8 giây 12.08 giây 11.6 lần
    bluesky 24.3 giây 2.01 giây 12.1 lần
    playwright 12.8 giây 1.16 giây 11 lần
    tldraw 11.2 giây 1.06 giây 10.6 lần

  • Tăng --checkers có thể giúp tăng tốc build bằng cách tận dụng nhiều lõi CPU hơn, nhưng thường đi kèm mức sử dụng bộ nhớ tăng lên

    • Trên các CI runner có ít lõi CPU và ít bộ nhớ, có thể giảm giá trị này để tránh overhead không cần thiết
    • --checkers 1 về cơ bản biến việc kiểm tra kiểu thành đơn luồng và loại bỏ công việc trùng lặp
    • Trong một số trường hợp hiếm, việc thay đổi số lượng --checkers có thể làm lộ ra kết quả phụ thuộc thứ tự, vì vậy việc chỉ định số checker cố định trên toàn bộ môi trường build có thể hữu ích

  • --builders

    • --builders kiểm soát số lượng project reference builder có thể chạy đồng thời khi thực thi --build
    • Điều này có thể đặc biệt hữu ích trong các monorepo có nhiều project
    • Tăng giá trị có thể giúp build nhanh hơn nhưng cũng có thể làm tăng mức sử dụng bộ nhớ
    • Có hiệu ứng nhân với --checkers, nên --checkers 4 --builders 4 có thể khiến tối đa 16 trình kiểm tra kiểu chạy đồng thời
    • Khác với --checkers, thay đổi số lượng --builders không nên tạo ra kết quả khác
    • Build project reference về cơ bản bị giới hạn bởi đồ thị phụ thuộc của project

  • --singleThreaded

    • --singleThreaded khiến toàn bộ compiler chạy trên một luồng duy nhất
    • Có thể hữu ích khi debug, so sánh hiệu năng giữa TypeScript 6 và 7, điều phối build song song từ bên ngoài, hoặc trong môi trường có tài nguyên rất hạn chế
    • Cờ này không chỉ giới hạn số lượng worker kiểm tra kiểu ở mức 1 mà còn khiến việc parse và emit cũng được thực hiện trên một luồng duy nhất

Chế độ --watch mới

  • TypeScript 7 đã làm lại hoàn toàn chế độ --watch
  • --watch mới cung cấp khả năng theo dõi tệp đa nền tảng hiệu quả và ổn định dựa trên file-watcher của Parcel bundler
  • Thư viện chuẩn Go không có API theo dõi tệp tích hợp sẵn, và các thư viện bên thứ ba đã được xem xét đều có vấn đề về độ ổn định, hiệu năng, hỗ trợ đa nền tảng và tích hợp công cụ build
  • Cách tiếp cận polling thuần túy hoạt động trên nhiều hệ điều hành, nhưng chi phí tính toán cao đối với các project lớn có nhiều phụ thuộc node_modules
  • Nhóm TypeScript đã port @parcel/watcher, vốn đã được dùng trong VS Code, sang Go và sử dụng shim assembly tối thiểu để tránh phụ thuộc vào toolchain C++
  • Watcher này là một package độc lập và mang lại cải thiện về mức sử dụng tài nguyên trên nhiều nền tảng trong chế độ --watch của TypeScript 7

Thay đổi về mặc định và tương thích trong TypeScript 6.0

  • TypeScript 7.0 được xây dựng để tương thích với hành vi kiểm tra kiểu và dòng lệnh của TypeScript 6.0
  • Mã biên dịch sạch bằng TypeScript 6.0 khi bật cờ stableTypeOrdering và không đặt ignoreDeprecations thì cũng phải biên dịch y như vậy trong TypeScript 7.0
  • TypeScript 7.0 áp dụng các giá trị mặc định mới của TypeScript 6.0, và sẽ phát sinh hard error đối với các cờ và cú pháp đã bị deprecated trong TypeScript 6.0
  • Những thay đổi chính về giá trị mặc định cấu hình như sau
    • Giá trị mặc định của strict là true
    • Giá trị mặc định của module là esnext
    • Giá trị mặc định của target là phiên bản ECMAScript ổn định hiện tại ngay trước esnext
    • Giá trị mặc định của noUncheckedSideEffectImports là true
    • Giá trị mặc định của libReplacement là false
    • Giá trị mặc định của stableTypeOrdering là true và không thể tắt
    • Giá trị mặc định của rootDir là ./
    • Giá trị mặc định của types là [], và có thể khôi phục hành vi trước đây bằng ["*"]
  • Thay đổi ở rootDir và types được xem là những thay đổi có thể gây bất ngờ nhất
    • Các project có tsconfig.json nằm ngoài thư mục mã nguồn như src cần chỉ định rõ rootDir để giữ nguyên cấu trúc thư mục hiện có
    • Các project phụ thuộc vào một số khai báo global cụ thể cần ghi rõ các package @types cần thiết trong types
{
  "compilerOptions": {
    "rootDir": "./src"
  },
  "include": ["./src"]
}

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

Hành vi đã bị loại bỏ hoặc trở thành hard error

  • Trong TypeScript 7.0, nhiều tùy chọn và cú pháp đã bị deprecated trong TypeScript 6.0 không còn được hỗ trợ nữa
  • Các mục chính gồm có
    • Không hỗ trợ target: es5
    • Không hỗ trợ downlevelIteration
    • Không hỗ trợ moduleResolution: node/node10, khuyến nghị dùng nodenext và bundler
    • Không hỗ trợ module: amd, umd, systemjs, none, khuyến nghị dùng esnext hoặc preserve cùng với bundler hoặc cơ chế phân giải module dựa trên trình duyệt
    • Không hỗ trợ baseUrl, và có thể cập nhật paths bằng đường dẫn tương đối theo gốc project thay cho baseUrl
    • Không hỗ trợ moduleResolution: classic, khuyến nghị dùng bundler hoặc nodenext
    • Không thể đặt esModuleInterop và allowSyntheticDefaultImports thành false
    • alwaysStrict được xem như true và không thể đặt thành false
    • Không thể dùng từ khóa module trong khai báo namespace
    • Không thể dùng từ khóa asserts trong import, cần dùng with để phù hợp với thay đổi cú pháp import attribute của ECMAScript
    • Chỉ thị /// <reference no-default-lib /> không còn được tôn trọng dưới skipDefaultLibCheck
    • Nếu thư mục hiện tại có tsconfig.json, build bằng dòng lệnh sẽ không thể nhận đường dẫn tệp và cần chỉ định rõ --ignoreConfig

Thay đổi về template literal type và hỗ trợ JavaScript

  • TypeScript 7.0 xử lý Unicode code point tự nhiên hơn trong suy luận template literal type
type HeadTail<S> = S extends `${infer Head}${infer Tail}` ? [Head, Tail] : never;

type Result = HeadTail<"😀abc">;
// 7.0: ["😀", "abc"]
// trước đây: ["\ud83d", "\ude00abc"]
  • Trước đây, theo hành vi indexing UTF-16 của JavaScript, "😀" bị tách thành hai phần của surrogate pair
  • Hành vi mới phù hợp hơn với trực giác coi "😀" là một đơn vị, giống như for...of hay [...str]
  • Điều này có thể là breaking change đối với các thao tác chuỗi ở cấp kiểu vốn cố ý mô hình hóa UTF-16 code unit
  • Hỗ trợ JavaScript cũng được làm lại để nhất quán hơn với cách phân tích tệp TypeScript
    • Không thể dùng value ở vị trí type, và phải dùng typeof someValue
    • @enum không còn được xử lý đặc biệt
    • Không thể dùng dấu ? đơn lẻ làm type, cần dùng any
    • @class không biến function thành constructor, cần dùng khai báo class
    • Không hỗ trợ postfix !
    • Tên type phải được định nghĩa bên trong thẻ @typedef
    • Không còn hỗ trợ cú pháp hàm kiểu Closure, cần dùng cú pháp rút gọn của TypeScript
  • Một số mẫu JavaScript như aliasing this và gán lại toàn bộ prototype của function cũng không còn được xử lý đặc biệt nữa
  • Khác biệt giữa TypeScript 6.0 và 7.0 được tổng hợp chi tiết hơn trong CHANGES.md

Tính năng và giới hạn của trình soạn thảo

  • TypeScript 7.0 bổ sung nhiều tính năng trình soạn thảo đã bị thiếu kể từ bản beta
  • Bao gồm tự động import, hover mở rộng được, inlay hint, code lens, go-to-source-definition, JSX linked editing, tag completion, v.v.
  • Các tính năng bị thiếu trong bản beta của TypeScript 7.0 như semantic highlighting, “sort imports”, “remove unused imports”, v.v. cũng đã được đưa vào
  • Để nâng cao chất lượng language server, nhóm đã tái xây dựng hạ tầng kiểm thử và chẩn đoán, đồng thời có thể thực hiện fuzz test trên các codebase TypeScript·JavaScript lớn trên GitHub

Các hạn chế hiện tại của quy trình làm việc ngôn ngữ tích hợp

  • Các workflow sử dụng Vue, MDX, Astro, Svelte, v.v. nhiều khả năng vẫn chưa thể tận dụng TypeScript 7
  • Các kiểu kiểm tra type cho template đặc thù như template Angular cũng nhiều khả năng chưa thể dùng TypeScript 7
  • Lý do chính là TypeScript 7 vẫn chưa cung cấp API lập trình ổn định
  • Các công cụ nhúng TypeScript vào compiler và language service riêng của mình như Volar hiện vẫn buộc phải phụ thuộc vào TypeScript 6.0
  • Nhóm TypeScript xem đây là hạn chế mang tính thời điểm và có kế hoạch phối hợp với các maintainer của những dự án đó để đảm bảo hỗ trợ TypeScript 7
  • Trước thời điểm đó, nhóm khuyến nghị dùng TypeScript 7 trong những kịch bản không cần language server plugin
  • Các dự án Angular có thể dùng tsc của TypeScript 7 trong CLI để phát hiện lỗi toàn dự án nhanh hơn, đồng thời tiếp tục dùng TypeScript 6.0 cho hỗ trợ trong trình soạn thảo
  • Vue, MDX, Astro, Svelte, v.v. sẽ vẫn cần tiếp tục dùng TypeScript 6.0 trong thời gian tới
  • Trong VS Code, có thể quay lại TypeScript 6.0 bằng lệnh “Disable TypeScript 7 Language Server”

Kế hoạch sắp tới

  • Việc phát hành TypeScript 7.0 là một cột mốc quan trọng của bản native port mà dự án TypeScript đã tập trung phát triển suốt hơn 1 năm
  • Sau 7.0, nhóm dự kiến quay lại phát triển tính năng mới, cải thiện khả năng sử dụng, tối ưu hiệu năng thêm nữa và triển khai API mới cho hệ sinh thái
  • Tương tự giai đoạn trước TypeScript 7.0, dự kiến sẽ phát hành bản tính năng mới mỗi 3~4 tháng
  • TypeScript 7.1 được lên kế hoạch để lấp đầy các khoảng trống và cung cấp API mới nhằm hỗ trợ cộng đồng chuyển đổi

Bài viết liên quan

2 bình luận

 
GN⁺ 2 giờ trước
Ý kiến trên Hacker News

  • Theo benchmark nội bộ, mức cải thiện tốc độ của TypeScript 7 như sau

    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

    Thật ấn tượng khi nhóm vừa migrate một cách có trách nhiệm vừa đạt được kết quả như vậy. Mong Bun nhìn vào mà học hỏi. Điều tôi tò mò là việc này sẽ ảnh hưởng thế nào đến các công cụ tầng dưới cần build codebase TypeScript như tsdown hay esbuild, và liệu có thể dùng TS 7 cùng với tsdown hiện tại không

    • esbuild hoàn toàn không phụ thuộc vào TypeScript nên không có vấn đề. tsdown thì tùy vào việc có dùng --isolatedDeclarations hay không; nếu không thì cứ cài song song TypeScript 6 như hướng dẫn trong bài blog
    • Tôi tò mò là bạn có cho rằng việc migration của Bun là vô trách nhiệm không

  • Trước đây từng có thời người ta tranh luận rằng type không đáng với công sức bỏ ra. Điều hay nhất của TypeScript trước hết là nó đã đại chúng hóa type

    • Tôi không nhớ rõ có ai ghét type. Thứ nhiều người ghét là static typing, chính xác hơn là static và explicit typing
      Ví dụ tôi từng nghe nhiều lần những câu kiểu “Python không dùng được vì không có type”, nhưng nói vậy là vô lý. Python là ngôn ngữ strong typed, đồng thời chỉ là ngôn ngữ dynamically typed mà thôi.
      Cũng có những ngôn ngữ thật sự không có type, hoặc thường được gọi là “stringly typed”. AREXX mà tôi từng nghịch hồi nhỏ thì mọi giá trị đều là chuỗi dù trông giống số, và hầu hết công cụ Unix CLI như sed cũng có thể xem là như vậy. Nhưng phần lớn tranh luận về type xoay quanh các ngôn ngữ dynamic typed như Python, và tôi hầu như chưa thấy ai nói rằng ngôn ngữ weak typed hoặc không có type là tốt cho dự án lớn. Ngược lại, tôi nghe nhiều người gọi nhầm Python là “không có type” rồi nói không thể dùng cho dự án lớn, điều này khá khó hiểu với tôi khi thực tế tôi đang xây các dự án lớn bằng Python
    • Type system ngày xưa đơn giản là khá tệ. Việc bị ép dùng class hierarchy để biểu diễn các type “OR” như sum types thật sự rất đau khổ. Các ngôn ngữ hiện đại có sum type như TypeScript, Rust, Swift, Kotlin dễ chịu hơn nhiều
    • Cá nhân tôi đã ba lần nói chuyện với những người gần như nói y nguyên rằng “tôi chưa từng gặp lỗi typing trong JavaScript”. Hai trong số đó là những người tôi tôn trọng công việc của họ, nên tôi rất khó hiểu sao họ có thể giữ quan điểm như vậy
    • Tôi nghĩ algebraic data types và pattern matching đã thay đổi cuộc chơi. Không cần đi quá xa như Haskell, type bỗng trở nên hữu ích hơn nhiều
      Trước đây, phần lớn trải nghiệm với type là C++/Java, đặc biệt C++ thì khó mà là ví dụ tốt cho thứ gì ngoài cách tạo ra một ngôn ngữ quá phức tạp. Một khi thấy type được áp dụng tốt, việc thuyết phục sẽ dễ hơn nhiều
    • Giờ chỉ còn chờ DependentTypeScript thôi

  • Điều thật sự ấn tượng ở đây là một đội ngũ tuyệt vời đã đồng thời duy trì hai codebase riêng biệt cho type system tiên tiến nhất mà nhân loại biết đến. Cũng rất mong bản viết lại bằng Rust

    • Tôi không chắc việc viết lại bằng Rust có ý nghĩa không. Go cho tốc độ viết code nhanh, và khi nhìn code thì dễ triển khai lại TypeScript theo kiểu 1:1
      Rust sẽ tốn thời gian phát triển lâu hơn nhiều. Rust có thể nhanh hơn Go 20%, nhưng mức cải thiện từ TypeScript sang Go đã đủ lớn rồi. Với vscode, có thể Rust cho 14x thay vì 11x của Go, nhưng chỉ Go thôi cũng đã đủ tạo ra khác biệt rất lớn
    • Có thể nói là phức tạp nhất, nhưng tôi không rõ có phải type system “tiên tiến nhất” không. Chắc không có đáp án đúng cho danh hiệu đó, nhưng một trong các ngôn ngữ proof assistant có vẻ là ứng viên hợp lý hơn
      Tôi không có ý hạ thấp type system của TypeScript; thực tế đây là một công trình rất thú vị
    • Steve Francia, người tạo ra Hugo và nhiều dự án Go quan trọng, có viết một bài về Go trong kỷ nguyên agent: https://spf13.com/p/go-the-agentic-language/
    • Tôi tò mò “type system tiên tiến nhất mà nhân loại biết đến” chính xác nghĩa là gì
    • Theo tôi biết, họ đã nghiêm túc xem xét Rust và các lựa chọn khác rồi mới chọn Go. Tôi không nhớ hết lý do, nhưng bài blog gốc có trình bày chi tiết

  • Sau vài năm dùng TypeScript, việc phải tự thêm type annotation trong Python và lôi các tính năng ngôn ngữ cơ bản như abc vào trở nên thật sự phiền phức

  • Thú vị đấy, nhưng giờ Node đã native strip type annotation của TypeScript nên tôi hầu như không chạy TSC nữa. Tôi chỉ chạy khi cần xem output tĩnh của compiler để kiểm tra những phần tạo ra breaking change lớn mà chưa cập nhật kịp
    Cả code frontend chạy trên browser cũng dựa vào cơ chế strip type của Node

    • Nói vậy đúng, nhưng mặt khác editor vẫn chạy TypeScript language server suốt cả ngày. CI có lẽ cũng vậy, và AI agent cũng sẽ làm thế trước khi chắc chắn về việc vừa làm

  • Thật vui khi cú pháp type của JSDoc tiếp tục được quan tâm. Đây là cách tôi thích nhất để dùng TypeScript trong các dự án cá nhân. Một số thay đổi cú pháp có thể sẽ hơi phiền khi cập nhật, nhưng phần lớn có vẻ là theo hướng tốt hơn

  • Nỗi đau lớn của TypeScript là khó điều chỉnh phạm vi cấu hình tsconfig như lib và types cho một phần của dự án
    Dự án là web app, nhưng vì vite.config.ts, Playwright và unit test nên phía công cụ IDE lại có type của Node lọt vào. Ngay cả khi thêm Node API vào component React thì tsc cũng không phàn nàn.
    Hiện tại, để cô lập thư viện DOM và thư viện Node, cần một mớ spaghetti project references, rất nhiều file tsconfig.json và file đầu ra tsbuildinfo; việc dùng project references mà vẫn tránh xuất type cũng rất phiền

    • Tôi đồng ý đây là phần thực sự đau đầu. Tôi đang dùng nx, và nó xử lý thay những việc như thế này. Playwright là một dự án riêng có tsconfig riêng, và tất cả đều kế thừa tsconfig ở root
      Ngay cả với ứng dụng đơn lẻ, tôi cũng thích dùng nx, và chuyển mã dùng chung sang “library”. Tôi dùng các library không build, và với dự án lớn thì khá ổn

  • Hiện vẫn chưa có TypeScript compiler API, nhưng nghe nói đang được làm nên rất đáng mong đợi

    • Dự kiến sẽ có trong 7.1

  • Nhìn vào biểu đồ cho thấy mức dùng bộ nhớ giảm và hiệu năng tăng mạnh, tôi lại nghĩ có lẽ phía server nên dùng Go thay vì TypeScript

    • Trước hết, phía server không chạy TypeScript. Dù dùng engine thực thi nào thì cũng là chạy mã đã được chuyển đổi hoặc JavaScript
      Và tôi cũng không rõ vì sao ngày nay vẫn có người bắt đầu dự án mới bằng TS/JS/Python trong khi đã có các lựa chọn khác
    • Có thể là vì có thể chia sẻ type hoặc module với dự án frontend. Cũng có thể vì với các ứng dụng không nặng về CPU thì gần như không có khác biệt, hoặc vì họ quen và thích. Ngoài ra hệ sinh thái thư viện cũng cực kỳ lớn
    • Đây là hiệu năng thời gian build, không phải hiệu năng thời gian chạy
    • Chênh lệch hiệu năng giữa Go và JS (Node, v.v.) có quan trọng hay không còn tùy trường hợp sử dụng. Với TypeScript compiler thì chắc chắn quan trọng, nhưng với app CRUD thì có thể hoàn toàn không quan trọng
    • Vì nếu có thể, làm việc bằng một ngôn ngữ chính sẽ dễ hơn

  • Chúc mừng đội ngũ TypeScript. Tôi có nhiều điều muốn viết thành bài dài hoặc nói qua audio, nhưng nói ngắn gọn thì hệ sinh thái JavaScript/TypeScript khá giống làm việc với gỗ
    Bạn có thể làm ra đồ kiểu Ikea, bằng gỗ ván ép laminate rẻ tiền. Nếu ví với code thì đó sẽ là một ứng dụng vibe coding không có gì độc đáo.
    Ngược lại, cũng có thể làm đồ nội thất thủ công cao cấp hoặc nhà cao tầng bằng gỗ. Kiểu như dùng gỗ non rồi bằng kỹ thuật ghép nối tùy chỉnh và ép lớp để tạo ra dầm chịu lửa. Trong hệ sinh thái JavaScript/TypeScript cũng có thể dùng AI như một máy công cụ mạnh mẽ, nhưng vẫn tạo ra kết quả cao cấp với tinh thần thủ công. Nếu có can đảm tạo ra thứ gì đó và chạy nó, thì cứ đón nhận hệ sinh thái TypeScript/JavaScript
 
GN⁺ 2 giờ trước
Các ý kiến trên Lobste.rs

  • Tôi hiểu lý do, nhưng việc chuyển từ compiler tự host sang một compiler không tự host khá thú vị
    Vì thông thường hầu như luôn đi theo hướng ngược lại, nên đây là một xu hướng hiếm thấy

    • Tôi nghĩ nên thấy hướng đi này thường xuyên hơn. Không phải ngôn ngữ nào cũng phù hợp để viết compiler
      Tự host tạo áp lực mạnh khiến ngôn ngữ tiến hóa theo hướng trở thành một ngôn ngữ viết compiler tốt hơn, nhưng điều đó không phải lúc nào cũng là hướng đúng
    • Thật ngạc nhiên khi nhà thiết kế và người triển khai ngôn ngữ hiểu rằng ngôn ngữ của họ không hoàn hảo cho mọi mục đích

  • Dù không code bằng TypeScript, bản thân VSCode được viết bằng TypeScript, nên tôi tò mò liệu cải tiến này có ảnh hưởng đến tốc độ VSCode không
    Hay nó chỉ ảnh hưởng đến extension ngôn ngữ TypeScript

    • Compiler nhanh hơn, chứ không phải bằng phép màu mà tạo ra mã chạy nhanh hơn
    • Chỉ áp dụng cho extension ngôn ngữ TypeScript
    • TypeScript được compile sang JavaScript. Khi VSCode chạy, node.js và Chromium thực thi mã JavaScript
      Thứ nhanh hơn ở đây chỉ là compiler nhận mã TypeScript và chuyển thành JavaScript; quá trình này diễn ra trong pipeline build trước khi Microsoft phân phối file thực thi VSCode
      Ngoại lệ tiềm năng có thể là server LSP TypeScript cũng nhanh hơn, vì nó thực sự parse mã TypeScript trong lúc chạy. Tuy nhiên, điều này tách biệt với việc VSCode được viết bằng TypeScript
    • Compiler TypeScript thực ra không làm quá nhiều việc. tsc có nguyên tắc là không nên động vào mã đang xử lý ngoài mức tối thiểu như loại bỏ kiểu, nên có khá nhiều thứ bị đánh dấu WONTFIX
      Vì vậy tôi dự đoán đặc tính hiệu năng của các công cụ làm bằng TypeScript gần như sẽ không thay đổi

  • Đây là một mẹo nhỏ cá nhân tôi rút ra. Dự án hiện tại tôi phụ trách dùng TS 5, nhưng đúng như dự đoán, tôi không muốn dùng nó trong nvim
    Vì vậy trước tiên tôi cài TS 7 bằng mise, rồi tạo một symlink tsgo trong node_modules/.bin trỏ tới TS được cài bằng mise
    Vì nvim-lspconfig vẫn dùng tên file tsgo cũ từ thời technical preview, nên nvim sẽ chạy TS 7 đã cài thay vì TS cục bộ