GN⁺: Node.js, TypeScript 실험적 지원 추가
(github.com/nodejs)모듈: --experimental-strip-types 추가
-
Node.js에서 TypeScript 파일 실행 가능
-
--experimental-strip-types
플래그를 설정하면 TypeScript 파일을 실행할 수 있음 - Node.js는 TypeScript 소스 코드를 JavaScript 소스 코드로 변환함
- 변환 과정에서 타입 체크는 수행되지 않으며, 타입은 제거됨
-
-
동기
- TypeScript 파일을 외부 종속성이나 로더 없이 실행할 수 있도록 하는 것이 중요함
- 사용자들이
node foo.ts
를 실행할 수 있기를 원함
-
타입 스트리핑의 의미
- 타입 스트리핑은 모든 타입을 제거하고 입력을 JavaScript 모듈로 변환하는 것
- 예:
const foo: string = "foo";
가const foo = "foo";
로 변환됨
-
@swc/wasm-typescript 선택 이유
- 간단함 때문
- 다른 도구들은 Rust나 Go를 추가해야 하지만, @swc/wasm-typescript는 작은 패키지로 wasm과 js 파일만 필요함
- Deno에서도 사용되고 있어 신뢰할 수 있음
-
제한 사항
- Enum, 네임스페이스 등 TypeScript 전용 기능은 변환되지 않음
- 확장자 없는 임포트는 지원되지 않음
-
향후 계획
- 네이티브 레이어에서 구현될 가능성 있음
- 소스 맵 지원을 추가할 수 있음
GN⁺의 정리
- Node.js에서 TypeScript 파일을 실행할 수 있도록 하는 새로운 기능에 대해 설명함
- TypeScript 파일을 JavaScript로 변환하여 실행할 수 있게 하며, 타입 체크는 수행되지 않음
- 이는 사용자들이 외부 종속성 없이 TypeScript 파일을 실행할 수 있게 하여 개발 환경을 단순화함
- 이 기능은 @swc/wasm-typescript를 사용하여 구현되었으며, 향후 네이티브 레이어에서의 구현도 고려되고 있음
- TypeScript와 JavaScript를 혼합하여 사용하는 프로젝트에 유용할 수 있음.
Hacker News 의견
-
TypeScript의 타입을 제거하는 것은 TypeScript의 문법 없이는 불가능함. 타입 제거는 토큰 수준의 작업이 아니며, TypeScript 문법은 계속 변화하고 있음
- 예를 들어,
foo < bar & baz > ( x )
는 TypeScript 1.5에서 다르게 해석되었음 - 새로운 TypeScript 기능을 사용하려면 JS로 컴파일하거나 Node 버전을 최신으로 유지해야 함
- Node LTS 릴리스를 사용하는 사람들에게는 타협이 어려울 수 있음
- 예를 들어,
-
Node.js가 TypeScript 파일을 직접 실행할 수 있다면 TypeScript 컴파일러는 타입을 제거하고 JavaScript로 변환할 필요가 없을 것임
- 이는 Python의 상황과 유사함
- Python에서는 여러 타입 체커가 존재하며, 모두 동일한 타입 힌트 문법을 사용하지만 다른 의미를 적용함
- JavaScript에서는 TypeScript가 유일한 인기 있는 타입 체커가 됨
- Python에서는 타입 힌트를 주석처럼 사용하는 사람들도 있음
- Node.js에서 타입을 무시하는 기능이 지원된다면 JavaScript에서도 가능할 것임
-
이 기능이 기본값이 된다면 NPM 생태계가 어떻게 반응할지 궁금함
- NPM 모듈을 게시할 때 CJS와 EJS 버전을 계속 빌드할지, 아니면
engine: nodejs >= 25
를 package.json에 추가하고 빌드 단계를 생략할지 고민됨 - 개인적으로는 TS로 작성된 NPM 모듈이 더 이상 dist/.cjs를 제공하지 않기를 바람
- 빌드 단계를 생략하는 것이 NPM 기여자들에게 유혹적일 것임
- 이는 NPM 생태계에 파급 효과를 일으킬 수 있음
- Node.js가 이 기능을 실험적 플래그 없이 제공하면 모든 소비자가 TS 파일을 수용할 것으로 예상됨
- 이는 Firefox와 Safari도 TS 파일을 수용하도록 강제할 수 있음
- 개인적으로는 JS 컴파일러가 TS 타입 주석을 버리는 것을 환영함
- Node가 .ts 파일을 수용하면 트랜스컴파일 단계를 제거할 수 있음
- NPM 모듈을 게시할 때 CJS와 EJS 버전을 계속 빌드할지, 아니면
-
Node가 JS에서 타입을 조사할 수 있게 되면 큰 이득이 될 것임
- Python에서는 pydantic 같은 도구가 존재하며, 이는 타입을 조사하고 검사를 생성함
- 이는 단일 표준 표기법으로 타입 검사, 런타임 데이터 검사, API 생성, API 문서 생성을 가능하게 함
- 현재 JS에서는 zod 같은 도구가 필요함
-
Bun의 개발자 경험(DX)은 이 분야에서 전례가 없으며, 대부분의 사용 사례가 충족됨
- Node에서는 import 시 확장을 요구하지 않도록 설정할 수 없으며, tsc가 .js 확장을 자동으로 추가하도록 설정할 수 없음
- 네이티브 TypeScript 지원이 이를 해결할 수 있지만, Bun의 사용자 경험이나 성능을 따라잡기 어려울 것임
-
TypeScript를 매우 즐기며 TypeScript 런타임을 갈망해왔음
- Java를 떠난 이유가 더 많은 기능을 가진 타입 시스템과 점진적 타이핑을 원했기 때문임
- npm 생태계의 단점에도 불구하고 라이브러리를 사용하는 것이 덜 부담스럽고 더 재미있음
- Rust는 다른 언어 스펙트럼에 있지만 유사한 느낌을 제공함
- JIT는 잘못된 용어였으며, JVM과 V8의 시작 시간과 런타임 차이를 말하고자 했음
-
내가 가장 좋아하는 deno 기능이 Node에 직접 도입됨
- esbuild를 설치하지 않고 타입을 제거할 수 있게 되어 매우 기대됨
- 최근에는 Python을 선호했지만, TypeScript가 Python보다 타입 면에서 더 나음
- 큰 스크립트는 타입이 있을 때 더 큰 이점을 가짐
-
Node에게 매우 중요한 한 달이었음
- v22.5.0에서 node:sqlite를 추가했고, 이제 TypeScript 지원이 도입됨
- Node의 방향성이 마음에 듦
-
PR 작성자임, AMA
-
오래 전 Node.js를 백엔드 작업에 사용하기 시작했으며, PHP보다 많은 이점을 제공함
- Node는 다소 번거롭고 원하는 언어로 만들기 위해 조립해야 했음
- Golang을 사용하기 시작했고, 타입 안전성 덕분에 코딩이 더 쉬워짐
- TypeScript는 좋은 옵션이지만 또 다른 부가 기능에 불과함
- Node를 사용하는 큰 이점은 프로토타입 작성 속도이며, TypeScript 사용으로 인해 이 이점이 상쇄될 수 있음