Using prebuildify instead of prebuild

[ghost]

Summary

Use prebuildify to bundle native code in the NPM package, instead of prebuild. prebuildify bundles prebuilt native code in the node_modules folder before a package is published. Although this would increase the size of the Keytar package by a few MB, it speeds up install time and has additional benefits listed below.

Motivation

I'm bundling an NPM package that needs to be installable offline from a TGZ, since some users have firewall restrictions. One of the dependencies I'm bundling is Keytar, which is inconvenient to install offline because it either downloads prebuilt code from GitHub, or requires that a user install node-gyp and its dependencies from online to compile the native code. If Keytar uses prebuildify, this would simplify the offline installation process.

More benefits of switching to prebuildify (taken from https://github.com/Level/leveldown/issues/482):

• No weird download prebuild issues - everything is available locally after a normal npm install
• No need for prebuild production deps - only a devDep is needed greatly reducing the dep chain
• Support changing node versions locally or using the same install between electron / node. All prebuilds are in the tarball and the correct one is simply picked on runtime.
• The module will work even if npm install scripts are disabled.

Describe alternatives you've considered

I've considered adding Keytar's prebuilt native code into the TGZ for my package, however there isn't an easy way to make prebuild-install find it in that location. There used to be a local prebuild feature in prebuild-install, which was removed in v5, so now it only finds prebuilt code in the NPM cache folder. When I raised an issue with prebuild-install about this, the recommended solution was for Keytar to use prebuildify (see https://github.com/prebuild/prebuild-install/issues/114#issuecomment-596061582).

[shiftkey]

Although this would increase the size of the Keytar package by a few MB, it speeds up install time and has additional benefits listed below.

For reference the total of the 47 prebuild archives from the previous release weighs in at ~2600KB.

There's a few things that aren't clear to me about this proposed change:

• How many people are encountering this issue and would actually benefit from the switch? The more 👍 I see on this issue, the better an indicator of the benefits of this change, but hearing more context here would be great.
• What's the migration story look like for the project? (seems to be a similar CLI experience to prebuild but I'd like to confirm)?
• By making this switch am I also breaking my existing users? what would they need to do if they rely on the things that prebuild does today?

[vweevers]

How many people [..] would actually benefit from the switch?

@shiftkey IMO (and in my experience with using prebuildify on leveldown) everyone, including you as a maintainer. Especially because users don't have to rebuild when switching node versions or runtimes.

seems to be a similar CLI experience to prebuild but I'd like to confirm

Mostly, yes. There's one additional step when publishing a new package version. Assuming you have CI setup to make prebuilds on a tagged commit, you wait for that to complete, then run prebuildify-ci download to download the prebuilds to your local machine, then npm publish.

By making this switch am I also breaking my existing users?

In some cases yes, for example when users are relying on additional tools like electron-rebuild (which would no longer be needed). I recommend a major bump.

[thegecko]

+1

This switch would be very useful for when the target architecture is unknown at build time, e.g. building a VSCode extension.