spruceid / siwe

Sign-In with Ethereum library
https://login.xyz
Apache License 2.0
1.05k stars 143 forks source link

isEIP55Address cannot be called because @spruceid/siwe-parser might be below 2.0.0 version #176

Open gssvv opened 1 year ago

gssvv commented 1 year ago

I faced that issue when I saw that error:

  if (!(0, siwe_parser_1.isEIP55Address)(this.address)) {
TypeError: (0 , siwe_parser_1.isEIP55Address) is not a function

I started to look into that and noticed that function isEIP55Address was introduced in @spruceid/siwe-parser version 2.0.0. And right now there's no dependency rule for that in siwe package.json: https://github.com/spruceid/siwe/blob/e3ca3cebddeff7707baa8826ce7524c27cd7595a/packages/siwe/package.json#L26

I believe that it must be set to ^2.0.0

A quick fix

If you're facing the same problem in your project, just install @spruceid/siwe-parser@^2.0.0. This will force siwe to use a newer version and the problem will be solved

w4ll3 commented 1 year ago

Are you using yarn, npm or pnpm? This might be related to the package manager.

gssvv commented 1 year ago

Are you using yarn, npm or pnpm? This might be related to the package manager.

I used npm in that case, but I think the logic would be the same for other package managers. E.g. you installed siwe-parser@1.x.x long time ago, it won't upgrade because there's not requirement for a higher version

JefferyHus commented 1 year ago

I am currently encountering the same problem. To address it, I had to specifically update the parser package using the command npm update @spruceid/siwe-parser. While attempting to update the siwe package, I faced an issue where the dependencies were not updated correctly. This appears to be more of an NPM-related problem rather than an issue with the individual package itself.

Furthermore, there is an option to specify the depth of packages to update using the command npm --depth N [package]. Regrettably, this approach didn't yield the desired results in my case.

Within the package-lock.json file, we can find the following details for the parent package:

    "siwe": {
      "version": "2.1.4",
      "resolved": "https://registry.npmjs.org/siwe/-/siwe-2.1.4.tgz",
      "integrity": "....",
      "requires": {
        "@spruceid/siwe-parser": "*",
        "@stablelib/random": "^1.0.1",
        "uri-js": "^4.4.1",
        "valid-url": "^1.0.9"
      }
    },

Additionally, there's another instance where the same nested dependencies mentioned above are specified:

    "node_modules/@spruceid/siwe-parser": {
      "version": "2.0.2",
      "resolved": "https://registry.npmjs.org/@spruceid/siwe-parser/-/siwe-parser-2.0.2.tgz",
      "integrity": "...",
      "dependencies": {
        "@noble/hashes": "^1.1.2",
        "apg-js": "^4.1.1",
        "uri-js": "^4.4.1",
        "valid-url": "^1.0.9"
      }
    },

The second occurrence reflects the version that was updated following the execution of npm update @spruceid/siwe-parser. Without this update, the previous version persisted, and interestingly, it was utilized instead of the nested version mentioned earlier.