Vincent Weevers

As a generic solution, we could support rest arguments and forward those as-is to `node-gyp`, e.g. `prebuildify --napi -- --force-process-config`. PR welcome, can be done by using [`opts['--']`](https://github.com/substack/minimist#var-argv--parseargsargs-opts) of minimist.

Are you using `--all` because you're not using Node-API? If so, I'm reluctant to approve this PR because we want to drop support of non-napi: https://github.com/prebuild/prebuildify/issues/57#issuecomment-979894415

Just curious, why would you want to? A major benefit of N-API is forwards compatibility. If you make a prebuild for node 8 it'll also work on 10, 12, 14...

> They may want to break something Not likely, that goes against its design philosophy. Note that including more prebuilds will increase your package size. Regarding the referenced issue, there...

For #10 we just need: ```js if (runtime === 'node') { // work around bug introduced in node 10's build https://github.com/nodejs/node-gyp/issues/1457 args.push('--build_v8_with_gn=false') } ``` Would you like to send a...

@bcomnes That is outdated by now. We can instead add the missing functionality to `node-gyp-build`, provided that it doesn't need new dependencies.

_Maybe_ a package rename is in order, but we can table that for now. PR(s) welcome!

To clarify, I thought it was okay to add functionality to the existing modules and that we could later choose to rename `node-gyp-build` to something more generic. But on second...

@mafintosh My point was, with the approach of `prebuildify-load`, there's no need to add cmake.

It's a good feature and doesn't add complexity. I'm for it, as long as it's semver-major because it will break `prebuildify-cross`.