fix(pnp): avoid using global URL

[llowrey]

• Added URL to import from 'url' package
• Necessary as fileURLToPath() will reject if not URL from 'url' package

What's the problem this PR addresses?
This addresses issue #5915. Some dependency, appears to have been react in my case, and under certain circumstances (may be specific to vitest, but maybe not), causes a call to new URL() which is rejected by a subsequent call to fileURLToPath() which, for node version < 20, will reject URL instances that aren't instances of the url package URL class.

This PR is able to easily fix the problem by including URL in the imports from the url package.

Resolves #5915
...

How did you fix it?

By adding URL to the import statements of a couple of yarnpkg-pnp files, the generated .pnp.cjs file will instantiate URLs via new url.URL() so that the resulting objects are acceptable by fileURLToPath().

...

Checklist

• I have read the Contributing Guide.

• I have set the packages that need to be released for my changes to be effective.

• I will check that all automated PR checks pass before the PR gets reviewed.

[merceyz]

This seems like something that should be fixed in Vitest.

[llowrey]

This seems like something that should be fixed in Vitest.

The problem I found while debugging within .pnp.cjs was that the URL instances it was creating were empty objects (console.log output was {}) but serialized to valid URLs (via .toString() or JSON.stringify()). My guess is that at some point in the bootup process, vitest, or some transitive dependency, is replacing global.URL with an implementation that is meant to emulate the in-browser URL class.

If that's true, perhaps vitest should be doing that later in the bootup process but I don't know if that is possible.

Regardless, this change hardens yarn. It is also not unprecedented as there are many other files in the project which import URL explicitly.

[merceyz]

Regardless, this change hardens yarn. It is also not unprecedented as there are many other files in the project which import URL explicitly.

That's fair I suppose, I've updated .eslintrc.js to prevent this from happening again and fixed the rest of them.

[arcanis]

It seems there's a legit issue with building the website:

11:52:05 AM: [success] [webpackbar] Client: Compiled with some errors in 25.06s
11:52:05 AM: Module not found: Error: Can"t resolve "url" in "/opt/build/repo/packages/plugin-git/sources"
BREAKING CHANGE: webpack < 5 used to include polyfills for node.js core modules by default.
11:52:05 AM: This is no longer the case. Verify if you need this module and configure a polyfill for it.
11:52:05 AM: If you want to include a polyfill, you need to:
11:52:05 AM: 	- add a fallback "resolve.fallback: { "url": require.resolve("url/") }"
11:52:05 AM: 	- install "url"
11:52:05 AM: If you don"t want to include a polyfill, you can use an empty module like this:
	resolve.fallback: { "url": false }

[arcanis]

Thanks @llowrey !