Node.js bổ sung hỗ trợ thử nghiệm cho TypeScript

 (github.com/nodejs)
3 điểm bởi GN⁺ 2024-07-26 | 1 bình luận | Chia sẻ qua WhatsApp

Mô-đun: thêm --experimental-strip-types

  • Có thể chạy tệp TypeScript trong Node.js

    • Khi đặt cờ --experimental-strip-types, có thể chạy các tệp TypeScript
    • Node.js chuyển đổi mã nguồn TypeScript thành mã nguồn JavaScript
    • Trong quá trình chuyển đổi sẽ không thực hiện kiểm tra kiểu, và các kiểu sẽ bị loại bỏ

  • Động cơ

    • Điều quan trọng là cho phép chạy tệp TypeScript mà không cần phụ thuộc hoặc loader bên ngoài
    • Mục tiêu là để người dùng có thể chạy node foo.ts

  • Ý nghĩa của việc loại bỏ kiểu

    • Loại bỏ kiểu là xóa toàn bộ kiểu và chuyển đầu vào thành mô-đun JavaScript
    • Ví dụ: const foo: string = "foo"; được chuyển thành const foo = "foo";

  • Lý do chọn @swc/wasm-typescript

    • Vì sự đơn giản
    • Các công cụ khác cần thêm Rust hoặc Go, trong khi @swc/wasm-typescript là một gói nhỏ chỉ cần các tệp wasm và js
    • Công cụ này cũng được dùng trong Deno nên có thể tin cậy

  • Hạn chế

    • Các tính năng chỉ có trong TypeScript như enum, namespace... sẽ không được chuyển đổi
    • Không hỗ trợ import không có phần mở rộng

  • Kế hoạch trong tương lai

    • Có khả năng sẽ được triển khai ở lớp native
    • Có thể bổ sung hỗ trợ source map

Tóm tắt của GN⁺

  • Giải thích về tính năng mới cho phép chạy tệp TypeScript trong Node.js
  • Có thể thực thi bằng cách chuyển tệp TypeScript sang JavaScript, nhưng không thực hiện kiểm tra kiểu
  • Điều này giúp người dùng chạy tệp TypeScript mà không cần phụ thuộc bên ngoài, từ đó đơn giản hóa môi trường phát triển
  • Tính năng này được triển khai bằng @swc/wasm-typescript và cũng đang được cân nhắc triển khai ở lớp native trong tương lai
  • Có thể hữu ích cho các dự án sử dụng kết hợp TypeScript và JavaScript.

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-07-26
Ý kiến Hacker News

  • Việc loại bỏ kiểu của TypeScript là bất khả thi nếu không có cú pháp của TypeScript. Loại bỏ kiểu không phải là công việc ở cấp độ token, và cú pháp TypeScript vẫn đang tiếp tục thay đổi

    • Ví dụ, foo < bar & baz > ( x ) đã từng được diễn giải khác trong TypeScript 1.5
    • Để dùng các tính năng TypeScript mới, cần biên dịch sang JS hoặc luôn cập nhật Node lên phiên bản mới nhất
    • Với những người dùng các bản phát hành Node LTS, đây có thể là một sự thỏa hiệp khó chấp nhận

  • Nếu Node.js có thể chạy trực tiếp các tệp TypeScript, thì trình biên dịch TypeScript sẽ không cần phải loại bỏ kiểu và chuyển đổi sang JavaScript

    • Điều này tương tự với tình hình của Python
    • Trong Python có nhiều trình kiểm tra kiểu, và tất cả đều dùng cùng một cú pháp type hint nhưng áp dụng ý nghĩa khác nhau
    • Trong JavaScript, TypeScript đã trở thành trình kiểm tra kiểu phổ biến duy nhất
    • Trong Python cũng có người dùng type hint như thể đó là chú thích
    • Nếu Node.js hỗ trợ khả năng bỏ qua kiểu, thì JavaScript cũng có thể làm như vậy

  • Nếu tính năng này trở thành mặc định, tôi tò mò hệ sinh thái NPM sẽ phản ứng thế nào

    • Khi phát hành mô-đun NPM, người ta có tiếp tục build các phiên bản CJS và EJS hay sẽ thêm engine: nodejs >= 25 vào package.json rồi bỏ qua bước build
    • Cá nhân tôi hy vọng các mô-đun NPM viết bằng TS sẽ không còn cung cấp dist/.cjs nữa
    • Việc bỏ qua bước build sẽ rất hấp dẫn với những người đóng góp cho NPM
    • Điều này có thể tạo ra hiệu ứng lan tỏa trong hệ sinh thái NPM
    • Nếu Node.js cung cấp tính năng này mà không cần cờ thử nghiệm, có thể kỳ vọng mọi bên tiêu thụ đều sẽ chấp nhận tệp TS
    • Điều đó thậm chí có thể buộc Firefox và Safari cũng phải chấp nhận tệp TS
    • Cá nhân tôi hoan nghênh việc trình biên dịch JS loại bỏ chú thích kiểu TS
    • Nếu Node chấp nhận tệp .ts, có thể loại bỏ bước transpile

  • Sẽ là lợi ích rất lớn nếu Node có thể xem xét kiểu trong JS

    • Trong Python có các công cụ như pydantic, chúng xem xét kiểu và sinh ra kiểm tra
    • Điều này cho phép kiểm tra kiểu, kiểm tra dữ liệu lúc chạy, tạo API và tạo tài liệu API bằng một ký pháp chuẩn duy nhất
    • Hiện tại trong JS, cần những công cụ như zod

  • Trải nghiệm lập trình viên (DX) của Bun trong lĩnh vực này là chưa từng có tiền lệ và đáp ứng hầu hết các trường hợp sử dụng

    • Trong Node, không thể cấu hình để không yêu cầu phần mở rộng khi import, và cũng không thể cấu hình để tsc tự động thêm phần mở rộng .js
    • Hỗ trợ TypeScript gốc có thể giải quyết điều này, nhưng sẽ khó bắt kịp trải nghiệm người dùng hoặc hiệu năng của Bun

  • Tôi rất thích TypeScript và đã luôn khao khát có một TypeScript runtime

    • Tôi rời Java vì muốn một hệ thống kiểu nhiều tính năng hơn và khả năng gradual typing
    • Dù hệ sinh thái npm có nhược điểm, việc dùng thư viện vẫn ít nặng nề hơn và thú vị hơn
    • Rust nằm ở một phần khác của phổ ngôn ngữ nhưng mang lại cảm giác tương tự
    • JIT là cách gọi không chính xác; điều tôi muốn nói là sự khác biệt về thời gian khởi động và thời gian chạy giữa JVM và V8

  • Tính năng deno tôi thích nhất đang được đưa trực tiếp vào Node

    • Tôi rất hào hứng vì có thể loại bỏ kiểu mà không cần cài esbuild
    • Gần đây tôi thiên về Python hơn, nhưng TypeScript tốt hơn Python về mặt kiểu
    • Các script lớn có lợi ích rõ rệt hơn khi có kiểu

  • Đây là một tháng rất quan trọng với Node

    • Ở v22.5.0 đã thêm node:sqlite, và giờ lại có hỗ trợ TypeScript
    • Tôi thích hướng đi của Node

  • Tôi là tác giả của PR, AMA

  • Từ lâu tôi đã bắt đầu dùng Node.js cho công việc backend, và nó mang lại nhiều lợi ích hơn PHP

    • Node hơi phiền phức và phải lắp ghép để biến nó thành ngôn ngữ mình mong muốn
    • Sau đó tôi bắt đầu dùng Golang, và nhờ tính an toàn kiểu mà việc lập trình trở nên dễ hơn
    • TypeScript là một lựa chọn tốt, nhưng rốt cuộc cũng chỉ là một tính năng bổ sung khác
    • Lợi thế lớn của việc dùng Node là tốc độ tạo prototype, và lợi thế đó có thể bị triệt tiêu khi dùng TypeScript