`@types/node` should be moved to devDependencies

[iSuslov]

Ethers Version

6.x.x

Search Terms

devDependencies

Describe the Problem

Hey, This package has @types/node is in dependencies instead of devDependencies. This was apparently added to fix Angular build issues in #3910, but I think that might not be the best solution.

Type definitions are only used during development and compilation - they serve no purpose in production builds. When users install ethers with npm i --omit=dev, they shouldn't need to download these type files.

I get the backwards compatibility concerns (https://github.com/ethers-io/ethers.js/pull/4893#issuecomment-2528929753) BUT, the errors mentioned in https://github.com/ethers-io/ethers.js/issues/3910 signaled by typescript and occur during development/build time when devDependencies are available anyway. If a project has issues with types, it's likely a configuration problem in that project that should be fixed upstream, rather than forcing all users to include type definitions in their production builds.

For that Angular project specifically, I tried to run the repo from https://github.com/ethers-io/ethers.js/issues/3910#issuecomment-1474743973 For that I needed to dedupe some dependencies in package.json and roll back ethers.js to the version prior to the "fix":

 "dependencies": {
    "@angular/animations": "16.0.4",
    "@angular/common": "16.0.4",
    "@angular/core": "16.0.4",
    "@angular/forms": "16.0.4",
    "@angular/platform-browser": "16.0.4",
    "@angular/platform-browser-dynamic": "16.0.4",
    "@angular/router": "16.0.4",
    "ethers": "6.3.0",
    "rxjs": "~7.8.0",
    "tslib": "^2.3.0",
    "zone.js": "~0.13.0"
  },
  "devDependencies": {
    "@angular-devkit/build-angular": "16.0.4",
    "@angular/cli": "16.0.4",
    "@angular/compiler-cli": "16.0.4",
    "@types/jasmine": "~4.3.0",
    "jasmine-core": "~4.6.0",
    "karma": "~6.4.0",
    "karma-chrome-launcher": "~3.2.0",
    "karma-coverage": "~2.2.0",
    "karma-jasmine": "~5.1.0",
    "karma-jasmine-html-reporter": "~2.0.0",
    "typescript": "~5.0.2"
  }

I was able to compile the repo after changing:

• in tsconfig.json: "moduleResolution": "node16"
• in package.json: "type": "module"

Proposed solution

I understand that not every project can change moduleResolution to node16 or nodenext so maybe the actual solution should be getting rid of resolution-mode in /// <reference types="node" resolution-mode="require"/> of types/providers/provider-ipcsocket.d.ts?

As per this https://github.com/microsoft/TypeScript/issues/56592#issuecomment-1832421446

resolution-mode="require" only emitted when the file references a global, ambient module

perhaps we can try import from "node:net" here:

https://github.com/ethers-io/ethers.js/blob/0195f440e35d11f84874f58d80b2071f52c4b17f/src.ts/providers/provider-ipcsocket.ts#L1-L8

[ricmoo]

The test-env CI was introduced in part to check all the possible variations of tweaking the /// <reference blah>, moduleResolution, etc., so if you want to try it out and see if it works, but keep in mind there are 7.2m downloads a month, so breaking backwards compatibility can be tragic and limits a lot of the types of changes we can make to the production library. :s

What is the problem you are having? Keep in mind that types should not introduce any generated code or increase code size, which is why I haven’t considered it a significant issue to resolve.

In the future v7 (which will contain no backwards-breaking changes for the majority of users), the IpcSocketProvider will be a separate package, so this issue goes away. It could also be resolved by providing an inline type definition of the Socket API, but last time I tried that it still had a lot of overhead that needed to be brought in and there was some issue (which I forget now). If it is a problem though, I can re-investigate that solution.

[ricmoo]

Closing this, as it is not a change that can be safely made in v6. Future major versions will move the IpcProvider to its own extension package, so this will be less of an issue.

[dynst]

https://github.com/ethers-io/ethers.js/blob/9fd9d41d017a5e3b329aca47c79786e69cd40b99/package.json#L15-L17

Can ethers at least stop pinning the dependency to a single version so people aren't potentially forced to install two versions of the same package?