如何在AWS CDK NodejsFunction Lambda中正确使用pdfmake类型？

问题根因 #

• @types/pdfmake的主入口文件仅导出运行时用的PdfPrinter类，没有对外暴露TDocumentDefinitions、StyleDictionary等接口类型
• 用普通require/import语法从pdfmake/interfaces导入内容时，CDK NodejsFunction默认的打包工具esbuild会将其识别为运行时依赖，尝试打包进产物，但pdfmake运行时代码本身没有暴露这个路径，最终Lambda运行时会报模块不存在的错误
• 未显式标注类型时，TypeScript会对单独声明的对象做字面量类型推导，推导结果和createPdfKitDocument要求的参数类型不匹配，触发类型报错，只能靠@ts-ignore绕过。

具体解决方法 #

1. 用纯类型导入语法导入类型，避免运行时加载 #

使用TypeScript的import type语法导入类型，这类导入会在编译阶段被完全擦除，不会生成任何运行时代码，从根源上避免模块找不到的问题：

// 导入运行时需要的主类
import PdfPrinter = require('pdfmake');
// 纯类型导入，编译后自动删除，不影响运行时
import type { 
  TDocumentDefinitions, 
  StyleDictionary, 
  TFontDictionary,
  BufferOptions
} from 'pdfmake/interfaces';

禁止用import xxx = require('pdfmake/interfaces')的写法，该写法会被保留为运行时依赖，触发模块找不到错误。

2. 给所有pdfmake相关对象显式标注类型 #

显式标注类型后即可获得完整的VSCode智能提示、非法属性标红能力，同时解决类型不匹配报错：

// 字体配置标注对应类型
const fonts: TFontDictionary = {
    Courier: {
        normal: 'Courier',
        bold: 'Courier-Bold',
        italics: 'Courier-Oblique',
        bolditalics: 'Courier-BoldOblique'
    },
    Helvetica: {
        normal: 'Helvetica',
        bold: 'Helvetica-Bold',
        italics: 'Helvetica-Oblique',
        bolditalics: 'Helvetica-BoldOblique'
    },
    Times: {
        normal: 'Times-Roman',
        bold: 'Times-Bold',
        italics: 'Times-Italic',
        bolditalics: 'Times-BoldItalic'
    },
    Symbol: {
        normal: 'Symbol'
    },
    ZapfDingbats: {
        normal: 'ZapfDingbats'
    }
};

// 单独声明的样式标注StyleDictionary类型
const styles: StyleDictionary = {
    p: { margin: [0, 0] }
};

// 文档定义标注TDocumentDefinitions类型
const docDefinition: TDocumentDefinitions = {
    content: [],
    styles, // 此处引入外部声明的styles不会再报类型错误
    defaultStyle: {
        font: 'Helvetica'
    }
};

const printer = new PdfPrinter(fonts);
// 传参时会自动做类型校验
const doc = printer.createPdfKitDocument(docDefinition);
doc.end();

3. 保留原有CDK配置即可 #

现有CDK代码中bundling.nodeModules: ['pdfmake']的配置不需要修改，@types/pdfmake仅在编译阶段生效，不需要加入运行时依赖列表。

4. TS配置校验 #

确认Lambda代码目录下的tsconfig.json默认开启了node_modules/@types目录的类型识别（绝大多数TS脚手架默认配置都支持，无需额外修改），即可正确识别pdfmake的类型定义。

效果验证 #

• 编码阶段VSCode会自动提示所有合法属性，属性名错误、值类型不匹配时会实时标红
• 外部声明styles等对象传入文档定义时，不会再触发类型不匹配报错，无需添加@ts-ignore
• 部署到Lambda后不会出现pdfmake/interfaces模块找不到的错误，PDF生成逻辑正常运行

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