SWC 不能直接替代 tsc，因其仅负责语法转译、不参与类型检查，无视 tsconfig.json 中 types/typeRoots/composite 等类型相关配置，且默认不生成 .d.ts、不支持调试需手动配 sourceMaps 和 launch.json。

VSCode 里用 SWC 替代 tsc 做 TypeScript 转译，确实能快很多，但默认不支持直接调试、不生成 .d.ts、且不能靠 tsconfig.json 全量控制行为——得手动配 swc 自己的配置文件。

为什么不能直接把 tsc 换成 swc 就完事

SWC 是 Rust 写的编译器，和 TypeScript 官方编译器（tsc）不是同一套逻辑。它不读 tsconfig.json 的所有字段，比如 "types"、"typeRoots"、"composite" 这些对类型检查关键的配置，SWC 完全无视；它只关心如何把 TS 语法转成 JS，不参与类型校验。

• tsc 是“类型检查 + 转译”一体化工具；swc 只干“转译”这一件事
• VSCode 的类型提示、跳转、错误红线，依赖的是 TypeScript 语言服务（即 tsserver），不是 SWC —— 换了 SWC 不影响编辑器里的类型体验
• swc 默认不输出 .d.ts 文件，也没 --declaration 这个开关；需要额外配 @swc/plugin-transform-typescript 或改用 swc-cli 的 --no-emit-tsc 等非标准方式（不稳定）

swc 在 Node.js 环境下怎么配才能跑通 ESNext

目标是让 src/index.ts 编译成 dist/index.js，输出符合 ESNext 语法（比如保留 export * as ns from 'x'、顶层 await、const 块级作用域等），且能被 Node.js v20+ 直接执行。

Zenlink - Node SDK for ZenHeart

ZenHeart zenlink 与 zenlink-mcp 为 OpenClaw，涵盖安装、MCP 注册、钩子接线、入站轮询及升级维护。

下载

• 装依赖：npm install -D @swc/core @swc/cli（不要装全局 swc，版本易冲突）
• 根目录加 swcrc 文件（注意没点）：

  {
    "jsc": {
      "parser": {
        "syntax": "typescript",
        "tsx": false,
        "decorators": true,
        "dynamicImport": true
      },
      "target": "es2022",
      "loose": false,
      "keepClassNames": true
    },
    "module": {
      "type": "commonjs",
      "strict": false,
      "strictMode": true,
      "lazy": false,
      "noInterop": false
    }
  }

• "target": "es2022" 是当前 Node.js LTS（v20.x）能原生支持的最高安全目标；真要强行用 esnext，得设 "target": "esnext"，但 Node.js 运行时可能报 SyntaxError: Unexpected token 'export' —— 因为 SWC 不会自动加 "type": "module" 到 package.json，也不会帮你切 require 为 import
• 命令行运行：npx swc src -d dist --config-file .swcrc

VSCode 里怎么触发 SWC 编译并保持调试可用

VSCode 默认的 Debug 启动器（launch.json）只认 .js 文件，且依赖 sourceMap。SWC 生成的 dist/index.js.map 是有效的，但必须显式开启：

• 在 .swcrc 中加："sourceMaps": true
• launch.json 配置保持不变，但 "program" 改为指向编译后的 dist/index.js：

  {
    "version": "0.2.0",
    "configurations": [
      {
        "type": "node",
        "request": "launch",
        "name": "Run with SWC",
        "program": "${workspaceFolder}/dist/index.js",
        "outFiles": ["${workspaceFolder}/dist/**/*.js"],
        "sourceMaps": true,
        "resolveSourceMapLocations": ["${workspaceFolder}/src/**"]
      }
    ]
  }

• 别删 tsconfig.json —— 它仍被 VSCode 用于类型服务；SWC 编译过程完全绕过它
• 如果用了 ts-node 或 tsx 做开发时运行，那 SWC 就只是构建阶段工具，两者不冲突

容易被忽略的兼容性断层

SWC 快，但快得有代价：它默认不处理 /// <reference types="..."></reference>、不展开 paths 别名、不校验 strictNullChecks 是否生效。这些都不是 bug，而是设计取舍。

• 路径别名（"paths"）需配合 @swc/plugin-module-resolver 手动启用，且该插件不支持嵌套 baseUrl
• 装饰器（@Component 等）必须开 "decorators": true，且 "emitDecoratorMetadata" 功能 SWC 不提供 —— 那部分得靠 reflect-metadata 运行时补
• Node.js 的 require('./utils') 加载 CJS 模块时，若 SWC 把 utils.ts 编译成 ESM 格式（export），就会报错；必须统一模块策略，或加 "module": { "type": "commonjs" }

真正要用 SWC 替掉 tsc，得接受它只做“语法搬运工”，类型、路径、元数据、声明文件这些，还得靠 TypeScript 生态其他工具各司其职。