Official strategy for caching of native packages

[nschonni]

This might be more of an NPM concern rather than a node-core thing, but I think it might be worth having a discussion here. Some of this might be things that are supposed to be replaced by NAPI.

Currently in node-sass, I just did a home-built pattern of of caching the binding downloads inside the NPM cache. Over our previous release in April 2018, we've had 71M downloads, but without caching it would have been around 3-4MB per install for each download.

It would be good to have a pattern from the node-gyp perspective on how native bindings should use to look-up and cache binding files.

/cc @xzyfer

[tniessen]

This discussion seems more appropriate for this repository than for the TSC. Transferred.

[nschonni]

Hi @tniessen I opened this in TSC since it covers a couple of the repositories under the responsibility of the TSC and from the TSC list of responsibilities

Setting overall technical direction for the Node.js Core project, including high-level goals and low-level specifics regarding features and functionality

[tniessen]

From what I understand, you are looking for a strategy for caching precompiled bindings? Based on my understanding, this is probably something that needs to be considered by npm or tools such as node-pre-gyp, is that right?

I'll ping the rest of the TSC to make sure moving the issue here was appropriate: ping @nodejs/tsc

[joyeecheung]

What does the "cache" refer to here? Pre-built binaries that do not require local compilation on user machines?

Some of this might be things that are supposed to be replaced by NAPI.

Can you elaborate on why N-API is relevant here?

[nschonni]

What does the "cache" refer to here? Pre-built binaries that do not require local compilation on user machines?

yes, there are some libraries using things like node-pre-gyp (which should maybe just be merged with node-gyp) to pull down bindings if available, and falling back to build if they don't exist.
Even when these prebuilts can be pulled down, there is no consistent story right now for caching, so installing a package in 2 different projects on the same machine has to download/build each time.

Can you elaborate on why N-API is relevant here?

With N-API offering a single binding for all OS platforms (unless I'm mistaken there), the thought process might have just to bundle up the single binding in the NPM package. With 30+ combos without N-API, that was never a viable option.

[tniessen]

Ping @nodejs/node-gyp, but I suspect that this might not be something we can do a lot about, this sounds like an issue with node-pre-gyp.

N-API offering a single binding for all OS platforms

That's not what N-API does. N-API provides an API/ABI that is stable across Node.js versions, but not stable across platforms. (I wish that was possible.)

[nschonni]

Sorry, I think it's getting lost again. node-pre-gyp has one implementation, but doesn't currently cache, I've built caching manually into a library.

The ask here is a discussion around caching of native bindings in the Node.js ecosystem. Whether they are downloaded or built locally. I get that caching is one of those "hard things in CS".

[tniessen]

For reference for anyone wanting to discuss this, there are already open issues / PRs about this in node-pre-gyp, even though they seem to be stalled:

• cache builds locally. mapbox/node-pre-gyp#101
• Add support for caching downloaded bindings. mapbox/node-pre-gyp#272
• Feature request: cache in OS tmpdir mapbox/node-pre-gyp#149

[nschonni]

Yes, node-pre-gyp has tried to tackle this, but seems to be a dormant project at this time. I would likely still switch node-sass to use it in the next version because it has become defacto standard because there is no guidance from node-core.

I opened this issue one TSC because I think it needs a discussion at the Node.js architecture level because native modules are a feature on the platform, and caching is something that is easily done wrong.

[guybedford]

If the binary fetch operation is designed to be idempotent, does using a package manager like pnpm mitigate the download cost by allowing it to be shared across projects? If so, perhaps advising this to your users could be an option?

[jasnell]

Has this been resolved? Does this need to remain open?

[nschonni]

No, it got transferred from TSC, and then nothing else happened

[bnoordhuis]

I've read through the issue twice and I'm still not sure what you want us to do, @nschonni. It seems like you should take this up with node-pre-gyp, dormant though it may be.