在React+Vite项目中解决pdfmake的vfs_fonts配置问题

问题背景

pdfmake是一个流行的PDF生成库，但在现代前端构建工具如Vite中配置虚拟字体系统(vfs)时，开发者经常会遇到各种问题。特别是在React+Vite项目中，传统的配置方式已经不再适用。

传统配置方式的问题

按照pdfmake的旧文档，通常会这样配置：

import * as pdfMake from "pdfmake/build/pdfmake";
import * as pdfFonts from 'pdfmake/build/vfs_fonts';

pdfMake.vfs = pdfFonts.pdfMake.vfs;

但在Vite+TypeScript环境中，这会引发两个主要问题：

1. 直接修改导入对象的属性在ES模块中是禁止的
2. 构建后的代码会出现"Object is not extensible"错误

解决方案探索

方案一：使用Object.defineProperty

Object.defineProperty(pdfMake, 'vfs', {
  value: vfs_fonts,
  writable: false
});

这种方法虽然能绕过TypeScript的检查，但在生产构建后仍然会失败。

方案二：修改导入方式

更可靠的解决方案是：

1. 首先处理字体文件：
   • 将vfs_fonts.js重命名为vfs_fonts.ts
   • 修改内容为标准的ES模块导出格式

// vfs_fonts.ts
const vfs = {
  'fontName-bold.ttf': '...base64编码的字体数据...',
  // 其他字体定义
};
export default vfs;

2. 在业务代码中使用动态导入：

import vfs from './vfs_fonts';

export const generatePdf = async () => {
    const { default: pdfMake } = await import('pdfmake/build/pdfmake');
    pdfMake.vfs = vfs;
    // 其余PDF生成逻辑
}

关键点说明：

• 必须使用const { default: pdfMake }的解构方式
• 动态导入确保模块系统正确初始化
• 字体文件需要转换为TypeScript模块格式

最佳实践建议

1. 字体管理：考虑将字体文件单独管理，而不是直接修改库文件
2. 构建优化：对于频繁生成PDF的应用，可以预加载pdfmake
3. 错误处理：添加适当的错误处理逻辑，特别是对于动态导入
4. 性能考量：大字体文件会影响包体积，考虑按需加载

总结

在现代前端工具链中使用pdfmake需要特别注意模块系统的限制。通过合理的模块化处理和动态导入技术，可以可靠地解决vfs_fonts的配置问题。这种方法不仅适用于Vite+React，也适用于其他基于ES模块的现代前端架构。