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/[email protected]/+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/[email protected]/+esm

• Search for Buffer (case sensitive+whole word)

/*!
 * The buffer module from node.js, for the browser.
 *
 * @author   Feross Aboukhadijeh <[email protected]> <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/[email protected]/+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/[email protected]/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/[email protected]/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/[email protected]/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.

[ST-DDT]

console.time("bundled")
await import("https://cdn.jsdelivr.net/npm/@faker-js/[email protected]/+esm");
console.timeEnd("bundled")
console.time("original")
await import("https://cdn.jsdelivr.net/npm/@faker-js/[email protected]/dist/index.js");
console.timeEnd("original")

Mostly:

bundled: 710ms
original: 976ms

Sometimes:

bundled: 204ms
original: 413ms

[ST-DDT]

We could push a single file build onto our website and use that instead of an external source (docs/public/faker.js).
That way we could even try new features from PRs in the previews.

Might be useful in combination with:

• Add refresh button to the api docs examples #3287

[xDivisionByZerox]

We could push a single file build onto our website and use that instead of an external source (docs/public/faker.js).
That way we could even try new features from PRs in the previews.

Lets discuss this issue on thursdays team meeting. Since this issue is only present on the website if you are using functions that call the internal base64-helpers, the scope of this bug is pretty limited. If you think this is more urgend, feel free to provide a PR with your suggestion of a fix.

[matthewmayer]

looks like there may be a way to stop jsdelivr adding the Buffer polyfill:
jsdelivr/jsdelivr#18263 (comment)

[ST-DDT]

Not urgent as no users have reported this error yet.

This might also affect users that bundle faker into production code for whatever reason and applying the partial polyfil. So the neat trick with node:buffer=false might be worth applying anyway.

I consider the browser self bundling a separate feature.

[ST-DDT]

Team Decision

• We will change our toBase64Url method, to always use toBase64().replaceAll() with a TODO comment pointing to the upstream issue