TypeScript ESM - Web3 has no construct signatures

[alex-mccreary]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

Following the Usage with TypeScript documentation results in error for ESM projects.

This expression is not constructable. Type 'typeof import("c:/Git/web3-esm-test/node_modules/web3/types/index")' has no construct signatures.ts(2351)

Expected Behavior

The new instance of Web3 is created.

Steps to Reproduce

package.json

{
   "name": "web3-esm-test",
   "version": "0.0.1",
   "description": "",
   "author": "",
   "private": true,
   "license": "UNLICENSED",
   "type": "module",
   "exports": null,
   "engines": {
      "node": ">=14.16"
   },
   "scripts": {
      "start": "nest start",
      "start:dev": "nest start --watch"
   },
   "dependencies": {
      "web3": "^1.8.0"
   },
   "devDependencies": {
      "@nestjs/cli": "^8.0.0",
      "@nestjs/schematics": "^8.0.0",
      "@nestjs/testing": "^8.4.7",
      "@types/express": "^4.17.13",
      "@types/jest": "^29.0.3",
      "@types/mocha": "^9.1.1",
      "@types/node": "^16.11.10",
      "ts-jest": "^29.0.2",
      "ts-loader": "^9.2.3",
      "ts-node": "^10.7.0",
      "typescript": "^4.8.2"
   },
   "jest": {
      "moduleFileExtensions": [
         "js",
         "json",
         "ts"
      ],
      "testRegex": ".*.spec.(js)?$",
      "transform": {},
      "collectCoverageFrom": [
         "**/*.(t|j)s"
      ],
      "preset": "ts-jest",
      "coverageDirectory": "../coverage",
      "testEnvironment": "node"
   }
}

tsconfig.json

{
  "compilerOptions": {
    "module": "ES2022",
    "moduleResolution": "node16",
    "declaration": true,
    "removeComments": true,
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "allowSyntheticDefaultImports": true,
    "esModuleInterop": true,
    "target": "ES2022",
    "sourceMap": true,
    "outDir": "./dist",
    "baseUrl": "./src",
    "incremental": true,
    "resolveJsonModule": true,
    "skipLibCheck": true,
    "types": ["jest", "node", "@types/jest"],
    "strictNullChecks": false,
    "noImplicitAny": false,
    "strictBindCallApply": false,
    "strict": false,
    "forceConsistentCasingInFileNames": false,
    "noFallthroughCasesInSwitch": false,
    "rootDir": "./",
    "typeRoots": ["./src/@types"]
  }
}

test.ts

import Web3 from 'web3';
import { BlockHeader, Block } from 'web3-eth' // ex. package types
const web3 = new Web3('ws://localhost:8546');

Web3.js Version

1.8.0

Environment

• Operating System: Windows 11
• Browser: N/A
• Node.js Version: 16.16.0
• NPM Version: 8.11.0

Anything Else?

No response

[Jack-Works]

A temporary patch. This NOT work for CommonJS users!

diff --git a/package.json b/package.json
index 114dcb5aedd67d4841b1bb68ab80e273f1d05871..e1713914fd51de471b09770a6ea644a07e4aff9c 100644
--- a/package.json
+++ b/package.json
@@ -18,7 +18,7 @@
         "API"
     ],
     "author": "ethereum.org",
-    "types": "types/index.d.ts",
+    "types": "types/index.d.mts",
     "scripts": {
         "compile": "tsc -b tsconfig.json",
         "dtslint": "dtslint --localTs ../../node_modules/typescript/lib types",
diff --git a/types/index.d.ts b/types/index.d.mts
similarity index 100%
rename from types/index.d.ts
rename to types/index.d.mts

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions. If you believe this was a mistake, please comment.

[shrpne]

I encountered the same problem.

Looks like it is caused by Web3 type exported as named export from .d.ts and actual Web3 module is exported as default.

So adding export default Web3 to web3.d.ts file should help

[CleyFaye]

As a temporary workaround for people using the library, without having to edit content in node_modules or other, one can declare custom types in project with something like this:

declare module "web3-eth-contract" {
  import {Contract} from "web3-eth-contract/types/index.js";

  export * from "web3-eth-contract/types/index.js";

  export default Contract;
}

Putting the above in a file (for example types/web3-eth-contract.d.ts and configuring this entry in tsconfig.json:

{
  "compilerOptions": {
    "typeRoots": [
      "./node_modules/@types",
      "./types"
    ]
  },
  "files": [
    "types/web3-eth-contract.d.ts"
  ]
}

(the files section is used with ts-node).

This is unlikely to break if/when the above PR gets accepted and published, allow reproducible behavior for now, and can be easily removed later.

[Muhammad-Altabba]

@alex-mccreary
Thanks for opening the issue. And could you please provide your input if the suggestion provided by @shrpne or @CleyFaye would resolve the issue? And if not, could you please share the full code for the scenario that produce the issue? I needed to modify your provided mentioned code to be able to check. But I would prefer if you can share a small sample repository or a link on some cloud editor like https://codesandbox.io/s/summer-sea-5rvxxg?file=/src/index.ts.

Thanks,

[Muhammad-Altabba]

@shrpne
Thanks for investigating the issue and proposing a possible solution with an MR...
However, regarding your comment:

So adding export default Web3 to web3.d.ts file should help

I would highlight that, the export default class Web3 ... is already there. And actually, in your MR, you applied the same for other packages. And this is good I think. But I would not expect it to fix this issue. However, since your MR is good to have. I made it available for other team members to review here. And if you still think that Your MR would fix the issue, could you please share the full code where you face the issue and where it would be resolved by your suggestion? You may use a cloud editor such as https://codesandbox.io/s/summer-sea-5rvxxg?file=/src/index.ts

And I would like also to point out that unfortunately module.exports = is not equivalent to export default. But as they are nearly identical and because they are used this way for web3 package. It is Ok and probably good to do the same for other web3.js packages. However, in version 4.x, the library is rewritten in TypeScript and such issues would not be present. And I encourage you to check the alpha version while the RC is also very close to being available.

Thanks,

[shrpne]

I would highlight that, the export default class Web3 ... is already there.

Well, looks like my PR indeed does not affect the author's issue.

My issue was the same but about separate packages: import Eth from 'web3-eth' was throwing TS errors

Thanks for merging

[Muhammad-Altabba]

For anyone who might still be facing this issue, please try to use // @ts-ignore before the line when you call the constructor on the imported Web3 object. So, try to use as in the following snippet:

import Web3 from "web3";

// @ts-ignore
const web3 = new Web3("http://localhost:8546");

console.log(web3);

And if the above solution does not work. Kindly provide a full but minimal code to replicate the issue, and share the repository on GitHub or on one of the cloud editors (like https://codesandbox.io/s/summer-sea-5rvxxg?file=/src/index.ts.)

[Muhammad-Altabba]

Hello @Jack-Works

Actually, in all cases, as mentioned in #5543 (comment), this issue would not be present in the next version (4.x) and it is already fixed there.

However, in version 4.x, the library is rewritten in TypeScript and such issues would not be present. And I encourage you to check the alpha version while the RC is also very close to being available.

[Jack-Works]

the migration guide is empty...
https://docs.web3js.org/