@mapbox/mapbox-gl-native not available (403 status code) on npm
mircowidmer opened this issue · comments
Platform: macOS
Steps to trigger behavior
- Run
npm install @mapbox/mapbox-gl-native
Expected behavior
I expect that the npm module is installed correctly.
Actual behavior
The tarball file can't be downloaded:
node-pre-gyp WARN Using needle for node-pre-gyp https download
node-pre-gyp ERR! install error
node-pre-gyp ERR! stack Error: 403 status code downloading tarball https://mapbox-node-binary.s3.amazonaws.com/@mapbox/mapbox-gl-native/v5.0.2/node-v72-darwin-x64-Release.tar.gz
node-pre-gyp ERR! stack at PassThrough. (/Users/mirco/Developer/external/graal-js-jdk11-maven-demo/node_modules/@mapbox/mapbox-gl-native/node_modules/node-pre-gyp/lib/install.js:137:27)
node-pre-gyp ERR! stack at PassThrough.emit (events.js:205:15)
node-pre-gyp ERR! stack at ClientRequest. (/Users/mirco/Developer/external/graal-js-jdk11-maven-demo/node_modules/needle/lib/needle.js:500:9)
node-pre-gyp ERR! stack at Object.onceWrapper (events.js:288:20)
node-pre-gyp ERR! stack at ClientRequest.emit (events.js:200:13)
node-pre-gyp ERR! stack at HTTPParser.parserOnIncomingClient [as onIncoming] (_http_client.js:565:23)
node-pre-gyp ERR! stack at HTTPParser.parserOnHeadersComplete (_http_common.js:116:17)
node-pre-gyp ERR! stack at TLSSocket.socketOnData (_http_client.js:452:22)
node-pre-gyp ERR! stack at TLSSocket.emit (events.js:200:13)
node-pre-gyp ERR! stack at addChunk (_stream_readable.js:294:12)
+1
Platform: Linux (Ubuntu 20.04 LTS)
Node: v12.17.0
npm: 6.14.4
Looks like their install instructions are out of date...
npm install mapbox-gl seems to do the trick
Scratch that ^ the above is specifically for mapbox-gl-js
Just ran into this today........
@markgis hard to tell. Would be great to see a working published version of native if possible!
Isn't that a Mapbox-gl-js fork, not Mapbox-gl-native?
Yep, looks like you're right, @markgis. Different packages, I'll update my comment above!
This error is happening because this library does not support prebuilt binaries for node 12. It is available on Node 10, however
I read somewhere (sorry will try and find the link) that the Mapbox team have stopped creating Node binaries all together and users will have to build themselves. Not sure.
@okdistribute Is it worth creating a fork just with later Node bindings? Probably a lot of work though to keep up with releases.
That's really unfortunate to hear! I can't get things to compile on my linux machine, and there isn't much in the CONTRIBUTING.md file. I don't really have time to go down this rabbit hole right now
@okdistribute So found the comment on another thread.
I would maybe be up for helping with post node 10 builds as tmpsantos suggests, but not sure how much time I have right now. I'm sure there are enough people who want native-gl compiled builds in node 12-14 to help out though?
Oh interesting. I don't have a ton of time to help out either, but I could do some basic things if necessary. I think we would benefit greatly from having this in native-gl in node 12. The newest versions of electron that have security upgrades and also depend upon Node 12.4, so until this is done, no electron application can use mapbox-gl native unless they use an insecure version of electron.
Right now as a workaround, we are running any necessary background mapbox-gl tasks using the javascript mapbox-gl library in an electron background window, which has access to the dom as well as node.js.
cc @gmaclennan
I've managed to create successful builds in Node 11 but not 12 yet. There was a V8 bump in Node 12 to 7.8.279.23-node.37 Node 10 was using 6.8.275.32-node.56 and I think thats where the issues lies.
I don't mind trying to create bindings and helping keep them up to date but I don't know enough about Cmake and NAN to fix it. I was hoping a nan version bump would solve it, but it looks like it's still broken.
I'm not sure if the issues lies with @mapbox/cmake-node-module which is used to create the bindings? Looking around it looks like a lot of people are now using N-API instead of nan.
Yeah, N-API is much more reliable and easier to work with, it has better asynchronous support as well IIRC. It may not a huge task to migrate from NaN to N-API, but it could take much longer if there is a snag along the way.
For anyone interested, we forked the node binding and added support for Node 12, 13, and 14 in naturalatlas/mapbox-gl-native-node@668a290 (still using NAN). The repo is here @naturalatlas/mapbox-gl-native. It uses the EGL backend because I for the life of me couldn't get the GLX backend compiling / working on Travis.
npm install @naturalatlas/mapbox-gl-native --save
@brianreavis I'm working on https://github.com/maptiler/tileserver-gl/ and it's having dependencies on this lib. I took the source code, replace with your lib and applied your 1.0.2 version number in package.json; apart from that had to replace in two other JS files also in the repo, and then did npm install -g - it was successful. But upon running it with a .mbtiles file, got this error:
Error: libOpenGL.so.0: cannot open shared object file: No such file or directory
at Object.Module._extensions..node (internal/modules/cjs/loader.js:1144:18) {
code: 'ERR_DLOPEN_FAILED'
}