将Remix应用部署到AWS Lambda时的两个esbuild相关疑问

1. 为什么需要两次esbuild构建？ #

Remix默认的npm run build是为适配它支持的常规服务器环境（比如Express、Architect原生服务器）做的构建，产物逻辑有两个核心点：

• 生成前端静态资源到public/build目录
• 编译后端代码到build/server目录，但这个产物是分散的模块集合，哪怕你配置了@remix-run/architect的createRequestHandler，Remix默认构建也只是把请求处理器作为模块的一部分，没有做Lambda适配的最终打包。

Lambda要求的是可直接加载的模块导出handler入口，且需要把运行依赖（除Lambda自带的）打包成适配环境的结构。第二次esbuild构建的作用就是：

• 以Remix构建后的服务器入口为起点，打包成一个直接导出exports.handler的单文件
• 调整模块格式为Lambda Node.js环境默认支持的CommonJS（如果Remix构建用了ES模块）
• 处理依赖打包逻辑，确保Lambda能直接加载运行

简单说：第一次构建是Remix完成自身的代码编译，第二次是把Remix的后端产物转成Lambda能识别的运行包。

2. 为什么esbuild无法解析aws-sdk依赖？ #

核心是esbuild的依赖解析逻辑和Node.js运行时的解析逻辑不一致：

• 开发环境下，Node.js允许加载全局安装的包、devDependencies里的包，旧版Node.js甚至自带aws-sdk，所以你的代码能正常运行。
• 但esbuild在生产打包时，会严格按照package.json的dependencies字段去node_modules里找依赖，如果aws-sdk不在dependencies中（没装或只装在devDependencies），esbuild就会报错找不到包。

而Lambda的Node.js运行时（Node.js 16及以下）自带aws-sdk v2，把它标记为外部依赖后，esbuild会跳过对它的打包，运行时直接用Lambda环境提供的版本，自然就解决了报错问题。

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