[bug?] constructors fail in production builds?

[Sjoerd82]

What could be a reason that PDFDocument.load() does work in development, but not in production? I'm thinking perhaps a problem with the minified version (related to #736?)?

    const pdfFile = await axios.get(url, {responseType: 'arraybuffer' })
    const pdfDoc = await PDFDocument.load(pdfFile.data)

Yields a valid pdfDoc structure in development (left part in screenshot) but fails with e => e in production (right part in screenshot

Any clues as to the origin of this difference and error, and/or how to troubleshoot it?
Many thanks for this beautiful library. 🥇

Edit: I've upgraded to 1.15 with the same result.
Versions:
"pdf-lib": "^1.14.0"
"pdf-lib": "^1.15.0"

Another thing I've noticed is on development the content-type includes mention of UTF-8:

Update 2021-01-21:
Still digging deeper...

While using the example PDF (dod_character.pdf) and example code, I still encounter the same phenomenon {e => e}, except that the output actually has correctly filled out the forms. I found that the reason behind this is that the example know up front which fields to expect with which data type, as such it can simply do:

const nameField = form.getTextField('CharacterName 2')

And as such is simply not affected by the weird e => e phenomenon.
In my form filler the fields are more dynamic, to deal with this I do

        formFields.forEach(feField => {
            const type = feField.constructor.name
            const name = feField.getName()

            // deal with the field, based on type.

        })

Which, by the way, I copied straight out of the AP docsI: https://pdf-lib.js.org/docs/api/classes/pdfform#getfields

const type = feField.constructor.name does not return the type, but simply "e". This is where everything falls apart.
Again, only in the production build, not in my development build.

In the meantime I had also learned that the e => e is related to the class constructors:
https://stackoverflow.com/questions/65828310/what-does-could-this-javascript-notation-e-e-signify

[Hopding]

See #933 (comment).