如何在NextJS中集成ts-runtime-checks自定义转换器？

方向一：通过Webpack配置接入TypeScript自定义转换器 #

Next.js默认使用SWC编译，但可以通过修改Webpack配置，让TS/TSX文件先经过ts-runtime-checks的转换器处理，再进入后续编译流程。具体步骤如下：

1. 安装依赖（若未安装）：

npm install ts-loader --save-dev

2. 修改next.config.js，添加Webpack配置：

const TsRuntimeChecks = require("ts-runtime-checks").default;

module.exports = {
  reactStrictMode: true,
  webpack: (config) => {
    // 定位处理TS/TSX文件的规则
    const tsRule = config.module.rules.find(rule => rule.test?.test('.tsx'));
    
    if (tsRule) {
      // 在原有编译流程前插入ts-loader，运行自定义转换器
      tsRule.use.unshift({
        loader: 'ts-loader',
        options: {
          transpileOnly: true, // 跳过类型检查，避免与NextJS自带的类型检查重复
          getCustomTransformers: (program) => ({
            before: [TsRuntimeChecks(program)]
          })
        }
      });
    }

    return config;
  }
};

这种方法无需修改ts-runtime-checks本身，能快速将转换器接入主编译流程，缺点是会引入额外的ts-loader处理步骤，编译速度略有下降。

方向二：为ts-runtime-checks构建SWC WASM插件 #

由于ts-runtime-checks是基于TypeScript AST的转换器，而NextJS的SWC插件系统要求操作SWC的AST结构，直接引用会报错。若要原生适配SWC，需要构建对应的WASM插件：

核心思路 #

1. AST结构转换：将SWC的AST转换为TypeScript AST，运行ts-runtime-checks的转换逻辑后，再转换回SWC AST。
2. 遵循SWC插件规范：使用SWC的插件API（推荐Rust编写，或实验性JS插件API）封装转换逻辑。

实验性JS插件示例（简化版） #

创建自定义SWC插件文件swc-plugin-ts-runtime-checks.js：

const TsRuntimeChecks = require('ts-runtime-checks').default;

module.exports = (swc) => {
  return {
    visitor: {
      Program: (ast) => {
        // 将SWC AST转换为TypeScript AST（需依赖SWC的AST转换工具）
        const tsAst = swc.typescript.astConverter.fromSwc(ast);
        // 运行ts-runtime-checks转换器
        const transformedTsAst = TsRuntimeChecks(swc.tsProgram)(tsAst);
        // 转换回SWC AST
        return swc.typescript.astConverter.toSwc(transformedTsAst);
      }
    }
  };
};

在next.config.js中引用该插件：

module.exports = {
  reactStrictMode: true,
  experimental: {
    swcPlugins: [[require.resolve('./swc-plugin-ts-runtime-checks.js'), {}]]
  }
};

注意事项 #

• SWC的JS插件API仍处于实验阶段，稳定性不足。
• AST转换过程可能存在兼容性问题，需要针对ts-runtime-checks的具体转换逻辑做适配。
• 若追求长期稳定性，建议用Rust编写原生SWC插件，编译为WASM后使用。

总结建议 #

• 优先选择方向一：实现成本低，能快速满足需求，适合大多数场景。
• 若对编译性能有极高要求，且有足够开发资源，再尝试方向二的SWC插件方案。

内容的提问来源于stack exchange，提问作者Mikolaj Figurski