ethersproject 5.5.0 BaseProvider ovewrite Provider failed

[hogan0520]

BaseProvider => resolveName(name: string | Promise): Promise<null | string>;
Provider => resolveName(name: string | Promise): Promise;

[ricmoo]

Good catch. Thanks.

Did you get a TypeScript error? Are there any others?

[Lumersgo]

same here when build with ether package

[hogan0520]

Good catch. Thanks.

Did you get a TypeScript error? Are there any others?

got a build error in Typescript

[holgerd77]

Not sure if related, but just to drop here: our Hardhat E2E tests on EthereumJS are currently also failing with some Ethers BaseProvider-mentioning errors.

[ricmoo]

@holgerd77 Is it using 5.5.0 too? I'll get a fixed release asap.

[ricmoo]

What version of TypeScript are you using?

I have made the changes, but would feel more comfortable if I could get TypeScript to emit errors; it is blindly accepting it. :(

[hogan0520]

Typescript: 3.9
Return type error function => resolveName, lookupAddress

[ricmoo]

Can you try using TypeScript 4.3 or 4.4?

It's weird it is complaining about the .on, because I don't think I changed that...

[ricmoo]

Oh! Actually, the .on and related errors are probably related to the previous errors. Since the previous errors determine that this is not a valid sub-class of Provider, they fail to allow a return type of this to match Provider.

The new version is passing through the CI. I'll ping you once I've published it...

[ricmoo]

I've published 5.5.1 if you can try it out?

[jeffreyzzzs]

#2181

[holgerd77]

@ricmoo I can't really see to what Ethers version dependency installation resolves in the CI, since it is just some subdependency for Hardhat. We are using TypeScript v4.4.2.

I've triggered a new dummy CI run here ethereumjs/ethereumjs-monorepo#1534 after the v5.5.1 release, if this passes (so the Hardhat E2E part) this should give additional assurance that the fix is correct.

[holgerd77]

Update: yes, Hardhat E2E tests are passing again. 😄 (might be worth to think if you also directly want to integrate these tests in your CI? Then you would be able to always test your latest master state towards the Hardhat test suite. Not sure how easily this would be adjustable though, but I could imagine it would be not too much work)

[hogan0520]

Fixed! THX!

[voltrevo]

It seems [email protected] mostly pulls in @ethersproject dependencies at version 5.5.0:

{
  "author": "Richard Moore <[email protected]>",
  "browser-old": "./dist/ethers.umd.js",
  "dependencies": {
    "@ethersproject/abi": "5.5.0",
    "@ethersproject/abstract-provider": "5.5.1",
    "@ethersproject/abstract-signer": "5.5.0",
    "@ethersproject/address": "5.5.0",
    "@ethersproject/base64": "5.5.0",
    "@ethersproject/basex": "5.5.0",
    "@ethersproject/bignumber": "5.5.0",
    "@ethersproject/bytes": "5.5.0",
    "@ethersproject/constants": "5.5.0",
    "@ethersproject/contracts": "5.5.0",
    "@ethersproject/hash": "5.5.0",
    "@ethersproject/hdnode": "5.5.0",
    "@ethersproject/json-wallets": "5.5.0",
    "@ethersproject/keccak256": "5.5.0",
    "@ethersproject/logger": "5.5.0",
    "@ethersproject/networks": "5.5.0",
    "@ethersproject/pbkdf2": "5.5.0",
    "@ethersproject/properties": "5.5.0",
    "@ethersproject/providers": "5.5.0", // <--- 😅
    "@ethersproject/random": "5.5.0",
    ...
  },
  ...
  "version": "5.5.1"
}

Is this normal?

Anyway pulling in @ethersproject/[email protected] seems to suffer from the original issue:

Check file:///home/voltrevo/workspaces/ethf/bls-wallet/aggregator/deps.ts
error: TS2416 [ERROR]: Property 'resolveName' in type 'BaseProvider' is not assignable to the same property in base type 'Provider'.
  Type '(name: string | Promise<string>) => Promise<string | null>' is not assignable to type '(name: string | Promise<string>) => Promise<string>'.
    Type 'Promise<string | null>' is not assignable to type 'Promise<string>'.
      Type 'string | null' is not assignable to type 'string'.
        Type 'null' is not assignable to type 'string'.
    resolveName(name: string | Promise<string>): Promise<null | string>;
    ~~~~~~~~~~~
    at https://cdn.esm.sh/v54/@ethersproject/[email protected]/lib/base-provider.d.ts:132:5

(Seeing this in deno trying to import https://esm.sh/[email protected].)

[ricmoo]

It seems [email protected] mostly pulls in @ethersproject dependencies at version 5.5.0:

Yes, that's normal. The patch version does not change. Otherwise, on every small change to any package, all packages would need to be re-published, and all audits would need to be performed on code that has zero changes except for the version in the package.json.

So, the patch can drift. The major and minor will always match though. :)