SST 项目中的异步配置导入问题解析

背景介绍

在 SST (Serverless Stack) 框架的 3.11.0 版本中，用户在使用 sst.config.ts 配置文件时遇到了一个关于顶层导入的限制问题。框架强制要求所有导入必须放在函数内部使用动态导入方式，这给一些需要共享配置代码的用户带来了困扰。

问题本质

SST 框架在 3.11.0 版本引入了一个严格的检查机制，禁止在配置文件顶层使用常规的 import 语句。错误提示建议用户将导入移到函数内部，并使用动态导入语法：

const mod = await import("./mod")

然而，这里存在一个矛盾点：app 函数默认不支持异步操作，导致用户无法按照错误提示的方式正确导入模块。这在需要从共享库中导入公共配置代码的场景下尤为棘手。

技术解决方案

SST 开发团队迅速响应了这个问题，在 3.11.1 版本中进行了修复，主要变更包括：

1. 允许 app 函数成为异步函数
2. 更新了类型定义以支持异步配置

修复后，用户可以这样编写配置文件：

export default $config({
  app: async (input) => {
    const commonConfig = await import("./common-config");
    return {
      name: commonConfig.getAppName(),
      // 其他配置
    };
  }
});

类型系统调整

在修复过程中，团队还发现了类型定义不一致的问题。最初生成的 .sst/platform/config.d.ts 文件中，app 函数的返回类型没有包含 Promise 类型，这与实际实现不符。这个问题在 3.11.21 版本中得到了修正，确保了类型系统的准确性。

高级用法建议

对于需要强类型返回值的场景，开发者可以采用以下模式：

1. 定义明确的返回类型接口
2. 在异步函数中确保返回值的类型正确性
3. 利用 TypeScript 的类型推断减少冗余代码

interface MyAppConfig {
  name: string;
  region: string;
  // 其他自定义配置项
}

export default $config({
  app: async (input): Promise<MyAppConfig> => {
    const config = await import("./config-helper");
    return config.generateConfig(input);
  }
});

最佳实践

基于这一问题的解决过程，我们总结出以下 SST 配置最佳实践：

1. 对于简单的配置，可以直接使用顶层定义
2. 对于需要动态生成的配置，使用异步函数
3. 共享配置代码建议封装为独立模块
4. 保持类型定义与实际实现一致
5. 定期更新 SST 版本以获取最新修复和功能

总结

SST 框架对配置导入限制的调整展示了其灵活性和对开发者体验的重视。通过允许异步配置函数，框架既保持了简洁性，又提供了足够的灵活性来应对复杂场景。这一改进使得开发者能够更好地组织配置代码，特别是在大型项目或需要共享配置的微服务架构中。