CDK Lambda NodejsFunction升级pdfmake0.2.5报data.trie缺失ENOENT错误

• pdfmake 0.2.x 依赖的新版pdfkit新增了文本断行计算逻辑，运行时需要读取内置的静态字典文件data.trie；0.1.x版本依赖的旧版pdfkit没有该逻辑，因此从0.1.64升级到0.2.5后才会触发这个报错。
• CDK的NodejsFunction默认使用esbuild做单文件打包，esbuild默认只会处理JS/TS代码，不会自动把依赖里的非JS静态资源复制到最终部署包，导致Lambda运行时找不到/var/task/data.trie文件抛出ENOENT错误。

无需修改PDF生成的业务代码，调整CDK打包配置即可解决：

• 方案一（推荐）：配置esbuild保留pdfmake的完整依赖目录
  在NodejsFunction的bundling配置中，将pdfmake加入nodeModules列表，配置示例如下：

  import { NodejsFunction } from 'aws-cdk-lib/aws-lambda-nodejs';
  import { Runtime } from 'aws-cdk-lib/aws-lambda';
  
  const pdfFunction = new NodejsFunction(this, 'PdfGenerateFunction', {
    runtime: Runtime.NODEJS_18_X, // 替换为你实际使用的Node.js运行时版本
    entry: 'lambda/pdf-handler.ts', // 替换为你的Lambda代码入口路径
    handler: 'handler',
    bundling: {
      nodeModules: ['pdfmake']
    }
  });
  

  该配置会让esbuild跳过pdfmake的单文件打包，转而在输出目录完整安装pdfmake依赖，包内自带的data.trie等静态资源会随部署包一并上传到Lambda，运行时即可正常读取。

• 方案二：手动复制静态资源到部署包
  如果你需要保持单文件bundle的打包形式，可以通过CDK打包钩子手动复制data.trie文件到部署包根目录：

  • 找到本地依赖中的data.trie文件，路径通常为node_modules/pdfkit/js/data/data.trie，若pdfmake为嵌套依赖则路径为node_modules/pdfmake/node_modules/pdfkit/js/data/data.trie
  • 在bundling.commandHooks的打包阶段添加复制命令，将该文件拷贝到打包输出目录的根路径，保证Lambda运行时能在/var/task下找到该文件。

你贴出的字体配置、PDF文档生成逻辑本身符合服务端运行要求，修复打包配置后即可正常运行。

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