원클릭으로
typescript
Building TypeScript packages (SWC, tsconfig, ESM)
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Building TypeScript packages (SWC, tsconfig, ESM)
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | typescript |
| description | Building TypeScript packages (SWC, tsconfig, ESM) |
Compiler docs: SWC · TypeScript Configs:
../../../tsconfig.build.json·../../../configs/swcrc.jsonc·../../../nx.json
All javascript code in this repo should use Typescript. The two exceptions are cli.mjs files that are required at the top-level for CLI-deployed packages, and eslint.config.js which needs to run pre-build. The logic in both should be trivial.
Typescript usage is strict, enforced both by Typescript itself and eslint's type-based rules. For example keywords like any are banned, and functions should declare their output type instead of just inferring.
To encourage type safe code, "chainable" methods (see packages like mocha-chain and juniper for examples) should be encouraged. That results in immutable objects (type cannot change implicitly) and instead returns an updated instance with an updated type.
This repo primarily uses vanilla typescript. Transformers (like babel plugins) are generally avoided until functionality becomes GA. Typescript is capable of handling the most common transforms (like React code).
The general goal is that the path from src -> dist should be fairly obvious. Import aliases are managed via package.json rather than tsconfig magic.
The actual transpilation is handled by SWC, which is generally faster than typescript. That implementation should be opaque to all users. Typescript is still in use for type checking, and actively reporting errors/providing intellisense in the IDE.
The target output is usually the latest ESNext. That is generally compatible with what is supported by server JS runtimes like Node. Frontend JS code will have its own packaging and backwards compatibilty support that is implemented separately.
Coding patterns and conventions (package design, types, DI, docs)
Creating a new package in the monorepo
Running CI locally with Dagger
Debugging (source maps, cache, test failures)
DevContainer runtimes, CLI tools, and version parity with Dagger
Installing a package dependency