chore(test): Switch rwjs/auth over to vitest

[Tobbe]

Switches @redwoodjs/auth over from jest to vitest.

The one weird thing is I had to make RWJS_API_GRAPHQL_URL a full URL, or mock-service-worker would throw an error about invalid URL. require() or import of whatwg-fetch also doesn't seem to make a difference, so I removed it. @jtoar and I spent some time looking into it yesterday, but couldn't get a full understanding exactly what was going on. It's something about what Request is being used.

MDN notes (emphasis mine)

A string containing the URL of the resource you want to fetch. The URL may be relative to the base URL, which is the document's baseURI in a window context, or WorkerGlobalScope.location in a worker context.

So it sounds like what we had should have been allowed. And it was with jest. But now, with vitest, for some reason it isn't anymore. My hunch is that require('whatwg-fetch') or import 'whatwg-fetch' isn't polyfilling Request anymore (for some reason), so msw is using some other version of Request that doesn't allow relative URLs. I haven't (yet) been able to verify that though.

There's a StackOverflow question here that sounds like it might be related. But difficult to know for sure. https://stackoverflow.com/questions/76046546/fetch-error-typeerror-err-invalid-url-invalid-url-for-requests-made-in-test
The answer there is to update to the latest version of msw

Found this in the msw docs

If you are describing a network behavior for a Node.js application, use the absolute URLs you are requesting [...] polyfill the document.baseURI string
https://mswjs.io/docs/basics/intercepting-requests#how-do-i-use-relative-urls-in-nodejs

The thing is though, that document.baseURI seems to already be polyfilled. So still not sure what's going on.

On main

With vitest

So definitely a different one. Not sure why though.

I can "fix" it by doing this

But I would still very much like to understand what's actually going on here.

UPDATE:

• whatwg-fetch gets loaded for both jest and vitest
• jest creates a vmContext that it loads its modules in
• vmContext is globalThis for modules. Basically what "window" is in a browser, but window.fetch (really globalThis.fetch) is undefined
• When whatwg-fetch is loaded and sees that there is no globalThis.fetch it polyfills fetch by attaching its own implementation of fetch to globalThis, and its own implementation of Request etc
• vitest loads modules using a normal node import statement.
• In node (>= v18) there is a globalThis.fetch
• When whatwg-fetch is loaded it sees that there already is a globalThis.fetch, so it doesn't try to polyfill anything

So that's the reason why there are two different versions of Request. And this is the reason why we need to manually set globalThis.Request = RequestPolyfill for vitest.

Furthermore, you can easily reproduce the "invalid url" error for relative urls in the Node version of Request by simply running node in your terminal and doing new Request('/relative'). As MDN states, relative urls are relative to the document's baseURI, but there is no document in node, so that's why you need full urls.

vitest does provide a value for document.baseURI, as we saw earlier (http://localhost:3000). But my guess here is that node's Request implementation doesn't even bother checking document, because it knows there will never be a document in the node environment. However, if you use a polyfill, like whatwg-fetch, they do look for document.baseURI and so it all works.

To keep the test (-environment) as close as possible to the jest environment we had I'm going to explicitly use the whatwg-fetch implementations of all its exports (rather than switching to a full url).