Next.JS Support

[SawkaDev]

Hi All. I am trying to do server side rendering and am using Next.JS as a framework. Is pdfmake compatible with next.js? My usage of pdfmake works fine in a normal 'node app.js' test. However, if I take it to next.js and put all the functions / pdfmake logic inside of /pages/api it keeps crashing here:

var pdfDoc = printer.createPdfKitDocument(docDefinition);

[liborm85]

I don't known what is next.js. After crash error is?

[sKopheK]

same here, i'm getting unexpected 404 even for basic example

[willyou]

same here.

nextjs is a framework.
It can allow developer to do SSR in easy way, and it has two kinds of backend.
One is called server action, another is called app route.

However, both of them can't use pdfmake and will lead to 404 response after we use the same code as the example from pdfmake github.

[AashisMhj]

Any update on this?

[liborm85]

No. Example or exact description of error for simulation was not provided.

[spicybackend]

I've hit this too, and just leaving some notes here in case it helps someone else. I don't really have the capacity to dive deeper at the minute.

Running using the development server does not output any error, it just silently fails and returns a 404 for the backend endpoint (an annoying quirk of Next.js in this case?). Happens on any API route. When trying to build a production version of the app, we get a bit more of a stacktrace and an error related to a missing data.trie file.

@repo/box-office:build: Error: ENOENT: no such file or directory, open '/apps/box-office/.next/server/app/api/inngest/data.trie'
@repo/box-office:build:     at Object.openSync (node:fs:581:18)
@repo/box-office:build:     at Object.readFileSync (node:fs:457:35)
@repo/box-office:build:     at 20102 (/apps/box-office/.next/server/app/api/inngest/route.js:38:124450)
@repo/box-office:build:     at t (/apps/box-office/.next/server/webpack-runtime.js:1:479)
@repo/box-office:build:     at 48071 (/apps/box-office/.next/server/app/api/inngest/route.js:38:259442)
@repo/box-office:build:     at t (/apps/box-office/.next/server/webpack-runtime.js:1:479)
@repo/box-office:build:     at 7906 (/apps/box-office/.next/server/app/api/inngest/route.js:200:33250)
@repo/box-office:build:     at t (/apps/box-office/.next/server/webpack-runtime.js:1:479)
@repo/box-office:build:     at 41461 (/apps/box-office/.next/server/app/api/inngest/route.js:201:3788)
@repo/box-office:build:     at t (/apps/box-office/.next/server/webpack-runtime.js:1:479) {
@repo/box-office:build:   errno: -2,
@repo/box-office:build:   code: 'ENOENT',
@repo/box-office:build:   syscall: 'open',
@repo/box-office:build:   path: '/apps/box-office/.next/server/app/api/inngest/data.trie'
@repo/box-office:build: }

Chasing up on other threads, it seems that other PDF libraries have had similar issues, and the root cause seems to stem from an upstream package, unicode-properties. This package now has a fix to serialize data.trie as a JSON file instead, however this is a few layers deep in the dependency chain, and those dependencies are also forks.

From what I can tell, the fontkit fork will need to be updated first to consume the fixed unicode-properties package.
https://github.com/foliojs-fork/fontkit/blob/master/package.json#L54
Then the fork of pdfkit.
https://github.com/foliojs-fork/pdfkit/blob/master/package.json#L52
And finally this package.

It seems that the fix would entail getting the foliojs forks up to date first, or this package switching from using the forks to the original repos, though it'd be up to the maintainers -- there's probably a good reason the forks are being used instead.