`internet.jwt()` fails on documentation website

[xDivisionByZerox]

Pre-Checks

• Follow our Code of Conduct.
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Faker issue and not related to a combination with another package.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.
• I am willing to provide a PR.

Describe the bug

When running faker.internet.jwt() on our documentation site, you receive an runtime error:

+esm:13 Uncaught TypeError: Unknown encoding: base64url
    at Uint8Array.Yi (+esm:13:5072)
    at Uint8Array.a [as toString] (+esm:13:5949)
    at ir (chunk-3QROWZCZ.js:1:5396)
    at kr.jwt (chunk-3QROWZCZ.js:1:18786)
    at <anonymous>:1:16

This might affect other browser environments as well (at least the ones using the same CDN).

Minimal reproduction code

Go to https://fakerjs.dev and open the dev tools.

Run the following:

await enableFaker();
faker.internet.jwt();

Additional Context

Our check for the existance of Buffer fails because the file (https://cdn.jsdelivr.net/npm/@faker-js/faker@9.2.0/+esm) loaded from the cdn includes a Buffer polyfill:

Environment Info

Tested in Microsoft Edge - Version 131.0.2903.63 (Offizielles Build) (64-Bit)

Which module system do you use?

• CJS
• ESM

Used Package Manager

npm

[xDivisionByZerox]

Would be glad if someone can confirm this bug.

[sounmind]

Same with me.

Environment Info

Mac, Chrome: 131.0.6778.69 (Official Build) (arm64)

[ST-DDT]

I can confirm the error as well on Firefox For Windows.
But I'm unable to explain it.

[ST-DDT]

Looks like it's getting poly filled:

https://cdn.jsdelivr.net/npm/@faker-js/faker@9.2.0/+esm

• Search for Buffer (case sensitive+whole word)

/*!
 * The buffer module from node.js, for the browser.
 *
 * @author   Feross Aboukhadijeh <feross@feross.org> <http://feross.org>
 * @license  MIT
 */

https://github.com/feross/buffer

[ST-DDT]

• add: base64url support feross/buffer#314
• Does not appear to support 'base64url' encoding like Node Buffer feross/buffer#309
• [bug] Unknown encoding: base64url feross/buffer#361

[xDivisionByZerox]

Looks like it's getting poly filled:

cdn.jsdelivr.net/npm/@faker-js/faker@9.2.0/+esm
[...]

I already came to the same conclusion in the "Additional Context" section of the issue. Still, I'm unable to grasp why this happens, since we have zero runtime dependencies..

[xDivisionByZerox]

Might the bundling from JSDelivery cause trouble? You can see at the top of the +esm file:

/**
 * Bundled by jsDelivr using Rollup v2.79.1 and Terser v5.19.2.
 * Original file: /npm/@faker-js/faker@9.2.0/dist/index.js
 *
 * Do NOT use SRI with dynamically generated files! More information: https://www.jsdelivr.com/using-sri-with-dynamic-files
 */
[...]

I tried the mentioned original file. When I do const { faker } = await import('https://cdn.jsdelivr.net/npm/@faker-js/faker@9.2.0/dist/index.js') our documentation site I can use faker without problems.

[ST-DDT]

I already came to the same conclusion in the "Additional Context" section of the issue. Still, I'm unable to grasp why this happens, since we have zero runtime dependencies..

Oh, I haven't seen that part.

I tried the mentioned original file. When I do const { faker } = await import('https://cdn.jsdelivr.net/npm/@faker-js/faker@9.2.0/dist/index.js') our documentation site I can use faker without problems.

Should we replace our import references?

[xDivisionByZerox]

Should we replace our import references?

I guess that would be the best to not rely on downstream implementations. 🤔

[ST-DDT]

I guess that would be the best to not rely on downstream implementations. 🤔

Yeah. especially since it seems to be stuck for many months now.

[xDivisionByZerox]

I checked again. The advantage of the +esm import is that the original file import fires 78 requests to retrieve all the chunks to load faker. This is about 50% slower from my quick testing. Can you run some tests on your end as well? Don't forget to disable the browser cache in the dev tools tho.