bchr02
Use of `remote_path` for tag is not ideal
Hi Bill -
I tried to submit a PR to the node-serialport project (see EmergingTechnologyAdvisors/node-serialport#1055) to split the host and remote_path portions of the node-pre-gyp spec in package.json. This was so that I could easily override the host used by node-pre-gyp to create private pre-built binaries for native node modules that don't have pre-built support for my target arch (ARM.)
As you can see in the linked thread, we ran into trouble because node-pre-gyp-github wants most of the remote path to be in the host portion of the specifier. It's mostly an annoyance as I noted a workaround in this comment but wanted to open an issue here in case you think anything can be done to improve how node-pre-gyp-github works in this regard. Maybe use a binary.tag specifier that is prioritized when present over remote_path?
FWIW here are some examples of the canonical (and IMO more intuitive) use of the host and remote_path options:
I understand this is probably not your top priority so happy to submit a PR if you are open to possible improvements. Thanks!
I'm definitely open to improvements. Send me a pull request so I can have a look. I prefer this not be a breaking change that would require a MAJOR release though if possible (and practical). Thanks.
yeah I'm thinking existing behavior would be preserved unless a new binary.tag attribute is present? And hopefully no existing users would have this already!
We can just make it a MAJOR release and put a section on the README about moving from one version to the other. No big deal. At least it's not going to require most people to rewrite anything unless the remote chance they are using binary.tag .