-
Notifications
You must be signed in to change notification settings - Fork 256
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Needed: New maintainership of node-pre-gyp #657
Comments
Following up here that I did not receive any comments or questions of interest. Also |
If there is interest from corporate users of the package for more active maintenance and/or tacking some of the more prominent open issues, I may be able to put time/work on this starting spring. Feel free to reach out if relevant. |
Can this unmaintained status be announced in the README.md? That may help to find new maintainers and quickly understand that the recent issues can not be resolved meanwhile. |
…stall` fixes #1641 fixes #1721 fixes #1714 fixes #1713 fixes #1700 fixes #1704 - `@mapbox/node-pre-gyp` is effectively unmaintained [1] as has a few bugs which our users keep running into - it seems the prebuilt binary world has moved in favor of prebuild + it's various other forms - one option would be to use prebuildify to bundle all binaries into the package, but that's a step too far removed from the current situation for now - instead, we can use prebuild-install to download the binaries, and `prebuild` to build + upload the binaries - this means we can remove node-pre-gyp and fix a bunch of issues! [1]: mapbox/node-pre-gyp#657
…stall` fixes #1641 fixes #1721 fixes #1714 fixes #1713 fixes #1700 fixes #1704 - `@mapbox/node-pre-gyp` is effectively unmaintained [1] as has a few bugs which our users keep running into - it seems the prebuilt binary world has moved in favor of prebuild + it's various other forms - one option would be to use prebuildify to bundle all binaries into the package, but that's a step too far removed from the current situation for now - instead, we can use prebuild-install to download the binaries, and `prebuild` to build + upload the binaries - this means we can remove node-pre-gyp and fix a bunch of issues! - eventually, we could start providing electron prebuilt binaries too [1]: mapbox/node-pre-gyp#657
…stall` fixes #1641 fixes #1721 fixes #1714 fixes #1713 fixes #1700 fixes #1704 - `@mapbox/node-pre-gyp` is effectively unmaintained [1] as has a few bugs which our users keep running into - it seems the prebuilt binary world has moved in favor of prebuild + it's various other forms - one option would be to use prebuildify to bundle all binaries into the package, but that's a step too far removed from the current situation for now - instead, we can use prebuild-install to download the binaries, and `prebuild` to build + upload the binaries - this means we can remove node-pre-gyp and fix a bunch of issues! - eventually, we could start providing electron prebuilt binaries too [1]: mapbox/node-pre-gyp#657
Is there anyone who still has maintenance access to this repo?I am an active maintainer of
@petersirota, @yhahn, @willwhite, @mapsam https://github.com/nodejs/node-gyp/issues?q=is%3Aissue+label%3A%22node-pre-gyp+is+unmaintained%22 |
As well as being a |
It's funny waking up to a flurry of activity from a comment made more than a year ago... anyway... I wrote the pull requests mentioned by @springmeyer in the original post (which apparently have rotted a little in the past two years) while on @solarwinds paycheque and using two weeks of their time. I'm (thankfully) not employed there anymore, and while I am way busier than I was when I made the offer @cclauss refers to, if there is a funding, I'd consider. |
@springmeyer Seems like this can be solved by forking the repo, however the real issue is npm publish permission. While you might not have access to publish Perhaps you could grant npm publish permission for |
Hi folks, @mapsam here from Mapbox, thanks for engaging here and we really appreciate the eagerness to help maintain node-pre-gyp! The project has sorely missed regular updates from us at Mapbox as the teams' priorities have shifted. I'm putting together a plan to help grant the proper access to those who are interested in maintenance and will respond back when I have more details. We're considering all options right now, from granting NPM access and GitHub access, or even transferring the repository entirely to a new maintainer. If you'd like to reach out to me directly with any ideas feel free to ping me here in this ticket or email me at |
I'm stepping down from maintaining
node-pre-gyp
. For the next month and a half (until the end of June) I can be available to a) facilitate moving maintainer-ship to someone else and b) be available to answer any questions on the transition from that new maintainer or the wider community (on this ticket).However I will no longer be reviewing PRs, making releases, or responding to bug reports.
As far as a new maintainer, that maintainer could be:
In my mind, all are good options and I will consider any proposals and try to decide promptly (by the end of June) to find a good solution that ensures a)
node-pre-gyp
is well maintained going forward for the benefit of the entire node.js community and b) also satisfies Mapbox needs.So, please comment on this ticket if you or your org are interested. Or reach out to me to discuss by emailing me at dane@mapbox.com.
Thanks!
For those curious for extra context and history, here is a quick summary.
Since 2013 I (@springmeyer) have been the primary maintainer of
node-pre-gyp
. Over this time I've tended to be the single point of contact both for internal Mapbox customers of node-pre-gyp as well as for the wider node.js community (fielding requests from companies using node-pre-gyp for mission critical modules as well as tending to the public github issue queue).I've recruited help from various Mapbox colleagues over the years (thank you especially @mapsam, and @wilhelmberg) and from countless generous open source contributors (like @Mithgol, @murgatroid99, @brianreavis, @jschlight, and @bmacnaughton). I'm especially grateful to these external folks for helping to keep things chugging during times when I've been in management roles without any time for coding.
Recently I've been away on parental leave and coming back I can see how important it is to find a new maintainer for this module.
The main reasons are:
node-pre-gyp
maintenance at the level the node.js community needs (for example, look at all the great work from https://github.com/mapbox/node-pre-gyp/pulls/ronilan that needs attention)The quick timeline of node-pre-gyp is that:
node-sqlite3
,node-srs
,node-zipfile
, etc)apt
,rpm
,homebrew
, etc) to handle binary deploymentnode-mapnik
andnode-gdal
) included binaries over 1-200 MB in size (per platform) we knew that a system that stored the binaries inside the package published to https://npmjs.com/ would not scale well (instead it would be more scalable to have a system to store the binaries separately, per platform)npm install
(this becamenode-pre-gyp
).node-pre-gyp
publicly such that the internal tool that helped us scale our AWS cloud deployments could also be used to handle binary deployment for windows users of node-sqlite3node-pre-gyp
would become nothing more than the "art of the possible" and would inspire the Node.js community to find a solution inside of node core that would avoid anyone needingnode-pre-gyp
.node-pre-gyp
and over time also additional projects like https://github.com/prebuild/prebuild.node-pre-gyp
. But two things caused friction: a) prebuildify tooling works by storing the binaries inside the npm package which works for most use-cases but not for the Mapbox use-cases that involve really large binaries for many different platforms (https://github.com/prebuild/prebuild-install#note) and b) by the time prebuildify was created I was working on totally different things at Mapbox than node.js c++ addon development so I never found time to address a) with any creative solutions.node-pre-gyp
only supports storing binaries on s3 (which was all Mapbox needed in ~2013) and does not support a) private modules, b) posting to github releases (like the third-party https://github.com/bchr02/node-pre-gyp-github allows), or c) allowing binaries inside of the npm package. All of these things seem quite reasonable to support to me, but are not something I will be able to help with. Hence this issue. Thanks for reading all the way to here :)/cc @flippmoke @aswamina @danpat @yhahn @mapbox/security-and-compliance
The text was updated successfully, but these errors were encountered: