fix: import EthereumProvider instead of default

[oxSaturn]

Description

I ran into this Uncaught (in promise) TypeError: EthereumProvider.init is not a function at WalletConnectConnector.initProvider_fn error when testing my React components with vitest, and I can saw multiple similar reports:

1. bug: TypeError: EthereumProvider.init #370
2. bug: EthereumProvider.init is not a function #379

The problem I found is how we use dynamic import in ESM like below https://github.com/wagmi-dev/references/blob/eeed52e2d0170324c53c145e54dc089761a414cb/packages/connectors/src/walletConnect.ts#L280-L284

Unfortunately, init is missing from EthereumProvider in this case.

I've set up a small example here where you can check the test.cjs file https://stackblitz.com/edit/stackblitz-starters-4alfhc?file=index.mjs, no bundlers like esbuild or webpack messing around, so it seems it's how the import works, though I haven't yet found the standard to reference.

Additional Information

• I read the contributing docs (if this is your first contribution)

Your ENS/address:

[changeset-bot]

🦋 Changeset detected

Latest commit: 04b393a

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@wagmi/connectors	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[oxSaturn]

FYI, I've posted a question on stackoverflow here https://stackoverflow.com/questions/76578030/static-method-on-javascript-class-becomes-undefined-after-imported

[oxSaturn]

All right, I can confirm it's a misuse in the code, when we import {default} from a CommonJS module, it actually imports the exports object, not exports.default. {default} is not a destructuring here.

see https://stackoverflow.com/a/76580524/22148155 for more.