npm install issues on latest master (Seaport support)

Hi, my package.json includes:

"opensea-js-seaport": "git+https://github.com/ProjectOpenSea/opensea-js.git#2e2d779cde7fcdda6298846de6b5f8dd32df8294",
"opensea-js": "3.0.2",

The 1st line has the latest master commit with Seaport support. The latter is the soon-legacy SDK which installs fine.

On npm install I’m getting an integrity check error:

14271 verbose node v16.11.0
14272 verbose npm  v6.14.15
14273 error code EINTEGRITY
14274 error Verification failed while extracting wyvern-js@git+ssh://[e-mail]/ProjectOpenSea/wyvern-js.git#f7704ad2571f05136f9a42735966dcd3f1485474:
14274 error Verification failed while extracting wyvern-js@git+ssh://[e-mail]/ProjectOpenSea/wyvern-js.git#f7704ad2571f05136f9a42735966dcd3f1485474:
14274 error sha512-KmmtiSg01F5PVtgl/nOhU7Lz2oSPGhv7lKSlqlbtUZCqa2JhvTnl0UVlzKAmTPDv/sYe6r8ol2e6pMg0paHObw== integrity checksum failed when using sha512: wanted sha512-KmmtiSg01F5PVtgl/nOhU7Lz2oSPGhv7lKSlqlbtUZCqa2JhvTnl0UVlzKAmTPDv/sYe6r8ol2e6pMg0paHObw== but got sha512-Wo9M/6+z/NyyR9jXVmwtSBDGPzJ/AeWEUrQuh1uBAc/YrFUOrm1dHL3MrY57yidzCnSaPoezW+p6SL6FRtMLrA==. (849531 bytes)
14275 verbose exit [ 1, true ]

I know the node+npm version combo is weird but after trying different setups between npm@6,7,8 and node@12,16 this got me the furthest. The integrity sha512 of the log is not part of the lock file so can’t delete that follwing the advice in https://stackoverflow.com/a/65983202. Using yarn is not an option in my case.

Thanks in advance! Excited for Seaport!

[marcelltoth]

@esteban-OpenSea I keep reading this argument when someone brings up the installation difficulties, but I don’t see why.

If you release a well-conforming package, any package manager should be able to install it. You can’t make someone swap out a major piece of their stack, just because your package doesn’t work well in some cases. It’s like saying “then use Firefox” when someone reports your site is broken in Chrome.

If you ever worked on a large scale JS project (let’s say a monorepo), you know that it may take a lot of effort to make the switch, even for testing purposes.

What do you mean by: “my suspicion is that the package-lock.json file might need to be updated.” ? NPM keeps package-lock up to date by default, there’s normally nothing manual needing to be done there. If you are going to suggest deleting it and installing from scratch, please don’t do that: it’s a nuke, it should be never needed, and on larger projects no-one will ever accept a PR that does so (and packs a 20k-line change in the lockfile)

I tell you what’s wrong:

When you are producing a library, you want to make sure it’s compatible with as much of the ecosystem as possible. This involves some things:

• In general it’s a bad idea to rely on non-standard or non-battle tested features, like:
  • git references
  • even worse: mutable git referrences
  • HTTP tgz references:
  • Reliance on lifecycle scripts
  • Those lifecycle scripts then make a lot of assumptions of the surrounding environment (package manager, OS, shell)
  • Submodules (again, combined with git references, so behavior depends on the consumer’s system)
• In general you want your dependency constraints as wide as you can, so you don’t cause duplicate dependencies (which lead to bundle size bloat and conflicts) for your consumers. Currently this is a nightmare, for example:
  • opensea-js@latest -> wyvern-js@7823dfdf5a272ebbc6a46e66d23563a9d6cc1be2 -> ethers@^4.0.49
  • opensea-js@latest -> ethers@^5.6.6
  • opensea-js@latest -> seaport-js@1.0.1 -> ethers@5.6.7 (note the fixed version here)
• Event wyvern-js is duplicated…
  • opensea-js@latest -> wyvern-js@7823dfdf5a272ebbc6a46e66d23563a9d6cc1be2
  • opensea-js@latest -> wyvern-schemas@0a8d569931ddb6faa6e96f5a60fa2f83f0a8750e -> wyvern-js@f7704ad2571f05136f9a42735966dcd3f1485474
• etc.

If you are interested I can perhaps give more guidance in the form of a consultancy session (or similar), but either way, these packages need a lot of cleanup before they are reliable for production usage. I’m currently considering cutting it from my project (and reimplementing required functionality by hand) as it’s making it totally unusable with the size bloat and installation flakiness: Since I installed my yarn install runs in CI fail about 40% of the time, with unchanging code. And I see multiple other folks reporting similar problems, too. Of course it may very well be all of us screwing up at the same time, but maybe the system is not as stable as we’d like it to be either 😉

[bmayen]

@marcelltoth, you are 100% correct. Unfortunately, all of these issues have been repeatedly brought up over many issues in this repo and have largely all been closed without being addressed. The project is poorly maintained, which isn’t a necessarily a problem in and of itself, but consistent feedback and offers to help go ignored, and that certainly is. We’ve come to the similar conclusion, at great personal financial expense, that this project’s definition of “production ready” is not remotely aligned with ours and it is all but unusable.