[BUG] Types JsonRpcProvider and SignerOrProvider are incompatible

[ustas-eth]

This simple code doesn't work with ethers v6.7.1 and typescript v5.2.2:

ethers.ts

import { JsonRpcProvider } from 'ethers'

export const provider = new JsonRpcProvider(process.env.RPC_PROVIDER)

eas.ts

import { EAS } from '@ethereum-attestation-service/eas-sdk'
import { provider } from './ethers.js'

export const eas = new EAS(process.env.EAS_CONTRACT)

eas.connect(provider)

Argument of type 'JsonRpcProvider' is not assignable to parameter of type 'SignerOrProvider'.
  Type 'JsonRpcProvider' is not assignable to type 'Provider'.
    The types returned by 'getNetwork()' are incompatible between these types.
      Type 'Promise<import("d:/Desktop/Hackathons/Newforum/EAS/node_modules/ethers/lib.esm/providers/network", { assert: { "resolution-mode": "import" } }).Network>' is not assignable to type 'Promise<import("d:/Desktop/Hackathons/Newforum/EAS/node_modules/ethers/lib.commonjs/providers/network").Network>'.
        Type 'import("d:/Desktop/Hackathons/Newforum/EAS/node_modules/ethers/lib.esm/providers/network", { assert: { "resolution-mode": "import" } }).Network' is not assignable to type 'import("d:/Desktop/Hackathons/Newforum/EAS/node_modules/ethers/lib.commonjs/providers/network").Network'.
          Property '#private' in type 'Network' refers to a different member that cannot be accessed from within type 'Network'.ts(2345)

[lbeder]

What version of the SDK are you using? Are you sure you're using ethers v6? Are you using its correct types? The same code works for me without any modifications.

[ustas-eth]

What version of the SDK are you using? Are you sure you're using ethers v6?

Should have attached the package.json as well, sorry

{
  "type": "module",
  "scripts": {
    "start": "ts-node --esm --files ./src/index.ts"
  },
  "dependencies": {
    "@ethereum-attestation-service/eas-sdk": "^1.2.0-beta.0",
    "dotenv": "^16.3.1",
    "ethers": "^6.7.1"
  },
  "devDependencies": {
    "@types/node": "^20.6.3",
    "@typescript-eslint/eslint-plugin": "^6.7.2",
    "@typescript-eslint/parser": "^6.7.2",
    "eslint": "^8.49.0",
    "eslint-config-standard": "^17.1.0",
    "eslint-plugin-import": "^2.28.1",
    "eslint-plugin-n": "^16.1.0",
    "eslint-plugin-promise": "^6.1.1",
    "ts-node": "^10.9.1",
    "typescript": "^5.2.2"
  }
}

Are you using its correct types?

ethers supports TS from the box

[lbeder]

I'm still unable to reproduce it. I've created a sample project with your package.json (including "type": "module") with an appropriate tsconfig.json and everything works, so perhaps the problem is with your tsconfig.json?

Can you try to reproduce it on a sample project yourself and share it with us?

[ustas-eth]

Node18 + Strictest tsconfig.json:

{
    "compilerOptions": {
    "rootDir": "src",
    "outDir": "ts-build",
    "lib": ["es2023"],
    "module": "node16",
    "target": "es2022",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true,
    "moduleResolution": "node16",
    "allowUnusedLabels": false,
    "allowUnreachableCode": false,
    "exactOptionalPropertyTypes": true,
    "noFallthroughCasesInSwitch": true,
    "noImplicitOverride": true,
    "noImplicitReturns": true,
    "noPropertyAccessFromIndexSignature": true,
    "noUncheckedIndexedAccess": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "isolatedModules": true,
    "checkJs": true,
  }
}

[lbeder]

It seems that your module resolution isn't fully compatible with ethers and how the SDK is compiled. Changing the configuration to "module": "CommonJS" and "moduleResolution": "node" seems to resolve this. Can you give it a shot?

[ustas-eth]

Yes, it did work. I think the problem is with the types of eas-sdk. In runtime everything is fine, I tried to ignore the line:

// @ts-ignore
eas.connect(provider)

[lbeder]

Both JsonRpcProvider and Provider are ethers types and are usually fully compatible (JsonRpcProvider implements AbstractProvider which implements Provider), unless they are imported in an incompatible way, which what happens in your case. Since no other project/protocol stumbled upon this problem - I'll resolve this issue for now.