upgrade to level(down) 5

[ahdinosaur]

this is an issue to track upgrading to level@5 and leveldown@5, once they are released:

• ssb-blobs: 1.2.1: ssbc/ssb-blobs@7bdc1d9
• flumeview-level: 3.0.9: flumedb/flumeview-level@4b84ae7
• ssb-invite: 2.1.1: ssbc/ssb-invite@7971392

[ahdinosaur]

i noticed this because leveldown@4 uses prebuild / prebuild-install as part of the native build step, i ran into an issue using prebuild-install with an npm cache proxy for PeachCloud builds (edit: turns out this was unrelated to prebuild-install), then went to test my latest fix and noticed leveldown is now using prebuildify (the same as what sodium-native is using).

[christianbundy]

Thanks for being so on top of this! I'm all for staying up-to-date with dependencies, please let me know if you need a hand.

[cryptix]

On a related note: I saw that the module tree of scuttle-shell still pulls version 3 for some plugins and I could use a hand with that.

I’m all for updating too. I just don’t want to pull three versions once this goes in and I’m having trouble finding out why some of them pinned to 3...

[staltz]

👍 But before merging any of these future PRs, wait for my confirmation that level 5 is working on mobile, because I think these prebuild tools sometimes get in the way and ship an x64 build of leveldown instead of an ARM build, which is the expected case for mobile.

[ahdinosaur]

@cryptix ah yep, seems flumeview-level is using level@3.

[vweevers]

Hi all, reaching out from Level, I have a couple of notes:

• The only change in level@4 is that it dropped support of node 4
• The upcoming level@5 will drop support of node 6 (due to limited N-API support)
• Keep an eye out for our upgrade guides ( UPGRADING.md in each repo/package)
• We would greatly appreciate beta-testing of leveldown: npm i leveldown@5.0.0-0. Post feedback in Release new major v5.0.0 Level/leveldown#550 or a new issue, anything is welcome.
• Nullish iterator range options have been refactored, which matters for flumeview-level because it uses bytewise, where null and undefined are significant types. Do you folks have a test suite that covers use of these types, so that we can do some canary testing?
• @staltz Re: ARM, could you open an issue in leveldown describing the needs? Let's join forces.
• Feel free to ping me on relevant ssb and flume issues. I reckon @ralphtheninja would be happy to help as well (if he isn't already, he's everywhere).

[ralphtheninja]

@staltz Re: ARM, could you open an issue in leveldown describing the needs? Let's join forces.

It would be really awesome if we could make this part of the upstream release process since it would potentially remove a lot of hands on tweaks in depending projects.

I imagine running a job on Travis, using a specific docker container to cross compile leveldown for ARM. It would require some testing though so we can be confident that node-gyp-build resolves the prebuilt binaries correctly.

[vweevers]

I forgot we already have an issue for ARM, thanks for finding it @ahdinosaur. Ref: Level/leveldown#360

Would that be the best place to discuss it though? It seems there's a common need for sodium-native, leveldown and others, and between them, enough experts (not me) to make it happen.

Also, now that node-gyp-build supports the npm --build-from-source flag (prebuild/node-gyp-build#13), at least there's a way for consumers to skip possibly mismatching prebuilds. Which means none of this is blocking a release of leveldown. Correct?

[ahdinosaur]

Which means none of this is blocking a release of leveldown. Correct?

@vweevers i'm not aware of any reason to block the release of leveldown, i think the question of how we build for ARM is something we can figure out as we go. /cc @staltz

[vweevers]

I released level v5.0.0-0, containing the leveldown prerelease and level-js for browser support. You can try it out with npm i level@next. Makes it easier to test leveldown too. Happy new year!

[vweevers]

leveldown@5 and level@5 have been released.

[staltz]

If I understand correctly, leveldown@5 doesn't allow undefined and null as keys anymore, but the SSB libraries rely heavily on this capability.

[vweevers]

@staltz I think (hope) you're referring to the use of bytewise/charwise for range options. E.g. { gt: null }. While the rules for keys and values have been restricted, the rules for range options have been relaxed, to allow the use of encodings like bytewise and charwise where nullish types are significant.

[staltz]

Okay, it could actually be that leveldown@5 is compatible with SSB libraries if levelup still supports null/undefined for (direct) keys and values.

[vweevers]

Can you point me to where nullish keys/values are used? If they are encoded (into something that isn't nullish) then it's not a problem.

[ahdinosaur]

closing, as i reckon this has been implemented:

• ssb-blobs: 1.2.1: ssbc/ssb-blobs@7bdc1d9
• flumeview-level: 3.0.9: flumedb/flumeview-level@4b84ae7
• ssb-invite: 2.1.1: ssbc/ssb-invite@7971392

these dependencies are also being used in the ssb-server shrinkwrap from 15.0.1.

cheers y'all! 😺