Simplify logic around abi crosswalk
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 1.2k
- Forks
- 271
- Avg merge
- 23h 40m
- Merged PRs (30d)
- 2
Description
### Context
When node-pre-gyp started node was at `0.8.x` and `process.versions.modules` had recently been added to node core to allow dynamically knowing the ABI version for a given node version.
node-pre-gyp needs to know this crosswalk in order to allow you to install a module for a given node version different than your host (important for packaging like https://github.com/mapbox/mapbox-studio-classic/blob/89bce13040c0ae3ff7c6c64371a8c428962c8b24/scripts/build-atom.sh#L81-L85). Instead of making you provide the ABI it makes sense to provide your exact node version you are targeting (MAJOR.MINOR.PATCH) and then node-pre-gyp is smart enough to grab the right ABI.
Two constraints existed:
> How to generate the crosswalk between node version and ABI and keep it updated?
In an effort to avoid extra network that might result in a build/install failure for node modules using node-pre-
gyp, I committed to storing the generated crosswalk inside a json file in node-pre-gyp.
> It was unclear at the time how that crosswalk would evolve. Would each node minor version bump the ABI or would each major version change it? Or would major versions get released that did not change the ABI?
Over time what happened is that:
- During the `0.x` series the minor version bumped the ABI during the even series but during the odd series the ABI got bumped even in patch versions. So, a cross walk of exact major.minor.patch was needed to tame the chaos.
- During the iojs phase of `1.x` releases the ABI version was bumped during a minor release.
- After the nodejs series started releasing `2.x` and above we've seen the ABI only get bumped with new major versions, predictably.
### Problem
This crosswalk is hard to maintain. Every time a node release happens (even a point release) it needs to be updated. And modules depending on node-pre-gyp also need to be updated if they use the `--target` flag and specific a release node version that node-pre-gyp does not know about. Tests in node-pre-gyp assert that it is updated, but this means the node-pre-gyp tests start failing after new releases of node, which is annoying and creates busywork.
### Solution
Here is a potential solution that keeps this functionality working but reduces maintenance burden.
- node-pre-gyp is modified to require an extra flag that points to an json file on the on the filesystem.
- That file would be in the format of https://nodejs.org/download/release/index.json
- it would be expected that users needing the `--target` flag would download https://nodejs.org/download/release/index.json and supply the path to it to node-pre-gyp
- On travis this would be tested such that every travis build would download https://nodejs.org/download/release/index.json and ensure it works to use.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Trace the existing --target handling, generated crosswalk, and tests that assert the crosswalk is current. Compare that flow with nodejs.org/download/release/index.json and the Travis test requirement; done means target resolution uses the supplied filesystem JSON and the updated test path works.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript, node.js
- Domain
- cli, tooling
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 28/100