Skip to content

Change from default to named export #1710

Open

Description

@blikblum

Feature Request

Change from default to named export

Feature description

const { PDFDocument } = require('pdfkit')

It should be a first step to implement features like pdfa extensions (#1705), plug in crypto (#885), export helpers (#976) without increasing the code size

@devongovett any thoughts?

Activity

  1. andreiaugustin commented on Mar 21, 2026

    @andreiaugustin
    Contributor

    This might also be the best opportunity to introduce tree shaking as well (#1570)!

    Perhaps a core/document.js which is a lean PDFDocument with no mixins applied? Each mixin becomes a higher-order class, extensions (pdfa, plug in crypto, einvoices) follow the same pattern.

    A default index.js composes everything for backwards compatibility and ensuring import PDFDocument from 'pdfkit' works exactly as today.

    Developers that care about bundle sizes can opt in:

    import { PDFDocument } from 'pdfkit/core'
    import { withImages } from 'pdfkit/mixins/images'
    import { withFonts } from 'pdfkit/mixins/fonts'
    
    const Doc = withImages(withFonts(PDFDocument))
    const doc = new Doc()
    

    Bundlers will drop anything not imported. I think we may need to set "sideEffects": false in package.json to signal to bundlers we safe to tree shake.

    A few more things to consider...

    Initialisation chain, mixins use a iniX() method called from the document constructor. With higher-order classes, each wrapper overrides the constructor and calls super(), allowing each layer to init itself.

    Dependency order, vector mixin depends on color; images depends on color. Probably best way to go about this is have each withX automatically compose its own dependencies, e.g. withImages internally applies withColor if not already applied (detectable through a static symbols/flag on the class).

    An exports map in package.json exposing pdfkit/core, pdfkit/mixins/* and possibly pdfkit/extensions/* or what they may end up being called.

    Perhaps this is also an opportunity to introduce typescript definitions? I don't personally use it, but I'm sure somebody out there might want it directly from PDFKit. The higher-order class patten makes this a good opporunity to add, each withX wrapper can ship its own .d.ts rather than trying to maintain one giant declaration file. Just worth considering!

    I'm happy to put together a proof of concept if you're interested, let me know !

  2. blikblum commented on Mar 21, 2026

    @blikblum
    MemberAuthor

    Perhaps a core/document.js which is a lean PDFDocument with no mixins applied?

    In medium term we can make something like that, but initially this issue is only to change to named export.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions