[Usage with Vitest/JSDOM] payload must be an instance of Uint8Array

[raulfdm]

What happened?

Hey folks 👋

I'm opening this issue just for cross-reference because I couldn't find anything in the repo.

I was writing a tiny function that generates a signed JWT from a payload and when I tried to write a unit test, it started failing:

TypeError: payload must be an instance of Uint8Array
 ❯ new FlattenedSign node_modules/jose/dist/node/esm/jws/flattened/sign.js:14:19
 ❯ new CompactSign node_modules/jose/dist/node/esm/jws/compact/sign.js:5:27
 ❯ SignJWT.sign node_modules/jose/dist/node/esm/jwt/sign.js:12:21
 ❯ Module.generateJWT src/generate-jwt.js:20:6
     18|     .setProtectedHeader({ alg: "RS256" })
     19|     .setExpirationTime("5m") // 5 minutes from now
     20|     .sign(privateKey);
       |      ^
     21|
     22|   return jwt;
 ❯ src/generate-jwt.test.js:13:17

After some investigation, I realize that this happened because I had JSDOM as test environment. The Uint8Array class used to encode the payload isn't the same when the Sign class use to check if it's instance of Uint8Array

If you're curious, watch this video

CleanShot.2024-05-06.at.15.51.52.mp4

I don't think there's nothing to you to do here though. Just opened this to have some cross reference because I couldn't find this problem reported anywhere.

Links

• https://github.com/raulfdm/jsdom-jose-crypto-bug
• Weird Uint8Array behaviour. Different classes? jsdom/jsdom#3711

Version

5.2.4

Runtime

Node.js

Runtime Details

node 20.10.0

Code to reproduce

- https://github.com/raulfdm/jsdom-jose-crypto-bug

Required

• I have searched the issues tracker and discussions for similar topics and couldn't find anything related.
• I agree to follow this project's Code of Conduct

[panva]

jest is also notorious for this nonsense with jsdom #441

As you said, there's nothing I can do here but ask myself why do tools insist on messing with globally exposed classes and why is this acceptable for its users.

Great video btw!

The root cause is also clear now: jsdom/jsdom#3711 (comment)

[raulfdm]

@panva Found the guilty: vitest-dev/vitest#5685

I don't have any context about why vitest needs to do such global class manipulation, but it's their fault.