Generating PDFs has long been a pain point for Go developers, with native libraries often requiring complex low-level operations. Enter pdfmakego, an innovative open-source project that sidesteps Go's PDF limitations by leveraging JavaScript's battle-tested pdfmake library—executed directly within Go via Google's V8 engine.

Article illustration 1

How It Works

  1. The Stack Dance: Go initializes a V8 isolate (using the v8go package) to run JavaScript.
  2. PDFMake Injection: The project loads pdfmake.js into the V8 runtime.
  3. Template Execution: User-defined JavaScript templates (like myScript.js) generate PDF definitions.
  4. Binary Extraction: The resulting PDF binary is passed back to Go for file creation.

The Navigator Hurdle

Initial runs failed with TypeError: Cannot read properties of undefined (reading 'navigator')—a classic browser-environment assumption in pdfmake.js. The fix? Commenting out FileSaver dependencies:

// var FileSaver = require('file-saver');
// var saveAs = FileSaver.saveAs;

This patch acknowledges pdfmakego's server-side context, where browser APIs don’t exist.

Why This Matters

  • Ecosystem Leverage: Tap into JavaScript's rich PDF tooling without leaving Go.
  • Performance Tradeoffs: V8 isolation adds overhead but offers sandboxed execution.
  • Edge Case Alert: Similar issues may arise with libraries assuming DOM/BOM APIs.
# Build Process
wget https://cdnjs.cloudflare.com/ajax/libs/pdfmake/0.2.12/pdfmake.js
go mod tidy
go build
./pdfmakego

The Polyglot Reality Check

While ingenious, this approach highlights integration friction when bridging runtime environments. Developers must audit third-party JS for implicit browser dependencies—a small price for accessing pdfmake's declarative PDF syntax.

As hybrid systems grow, expect more projects dancing between languages. Just pack your debugging gloves. // Source: pdfmakego GitHub