node package improvements

[springmeyer]

Currently the node bindings include, in the package.json, a fallback to source compiles:

mapbox-gl-native/package.json

Line 52 in daf8e12

"install": "node-pre-gyp install --fallback-to-build=false || make node",

This is non-desirable for 3 reasons:

• It's confusing: when a binary is not available, first a user is presented with lots of lines of errors before the source compile starts, eroding confidence in the build, even if the source compile later succeeds.
• The source compile is unlikely to work. Users running npm install expect a binary and don't likely have the correct development environment to source compile. So in the rare circumstances where this fallback is triggered we should fail fast rather than try to fallback.
• Keeping support for source compile fallbacks leads to an enormous package tarball. Currently the package for @mapbox/mapbox-gl-native on npm is 244 MB on disk due to the large ./vendor folder (`166 MB itself)

So, my proposal is to:

• Expect that users who run npm install will only get a binary, if available
• Stop falling back to a source compile
• Document in the developing.md that to compile mbgl source a user needs to:
  • clone from git
  • run make node
• Add an .npmignore to radically trim the size of the uploaded package on npm

/cc @mapbox/gl-native @mapbox/static-apis @kkaefer

[springmeyer]

With these changes the size on disk is now 172 kb

[springmeyer]

Another option I considered to reduce package size while avoiding having to declare all these things is to move the package.json into platform/node/ and do the packaging from there. But that would be more distruptive of a change, so I did not take that route.

Also, I wish there was such a thing as .npminclude but it does not exist: npm/npm#13171

[springmeyer]

This change means that npm install will still work and fetch a binary. But if a binary is not found the install will exit instead of calling make node.

[springmeyer]

It appears that make xnode does not exist anymore so I removed reference to it. Not sure when the xnode target was removed /cc @friedbunny @tmpsantos

[springmeyer]

removed this since i can't find any sign of its existence anymore

[springmeyer]

We are only supporting + building with node v10 currently, so this drifted out of date

[springmeyer]

👋 @brendan-ward @petrsloup @klokan - I noticed you are maintainers of modules that depend on @mapbox/mapbox-gl-native (based on https://www.npmjs.com/package/@mapbox/mapbox-gl-native). Are any of you critically depending on the ability to run npm install @mapbox/mapbox-gl-native and have it fallback to a source compile? This PR removes that functionality which means that going forward:

• npm install @mapbox/mapbox-gl-native will only install binaries
• currently binaries are available for node v8, v10, and v12
• if binaries are not available then the build still stop
• if you want to source compile for a version of node that does not support binaries you'd need to clone the github repo and run make node

Let me know if you have any concerns.

[brendan-ward]

@springmeyer thanks for reaching out!

I believe that we will be fine with just binary versions; I was only relying on building from source until the binaries became consistently available (~4.0?). I 👍 the idea of reducing the package size as we go to some lengths in our Dockerfile to reduce some of these build dependencies.

The only place where I've been trying to build from source is in trying to setup a new alpine-based Docker image, which has not been successful yet due to GL issues, and for that I totally expect to clone the repo and build from source as part of the build chain - NOT via npm install.

So - I think your assumptions above are valid for our use case.

[springmeyer]

Great, thanks so much for the confirmation + feedback @brendan-ward. I'm also interested in alpine. I've had success with other projects on alpine, but have not attempted mbgl-native yet. Feel free to cc me on tickets where you are exploring that - I would be interested to take a look.

[petrsloup]

@springmeyer Thanks for letting us know! We don't have any issue with this change -- we usually use mapbox-gl-native in a controlled docker environment (debian-based) and the prebuilt binaries are just fine.

[springmeyer]

@petrsloup excellent, thanks for confirming. That's a relief. Glad to know that the pre-built binaries work well in the docker setup too.

[ian29]

thank you for putting to this together @springmeyer