feat: Add --cpu and --os option to override platform specific install

[yukukotani]

Add --cpu option and ---os option which is proposed in npm/rfcs#612.

The change of npm-install-checks package is here: npm/npm-install-checks#65

Real Example

Let's think about the package.json below:

{
  "name": "demo",
  "version": "1.0.0",
  "dependencies": {
    "@node-rs/xxhash": "latest"
  }
}

Running npm i on my M1 mac machine will install two package @node-rs/xxhash and @node-rs/xxhash-darwin-arm64.

Running npm i --cpu x64 --os freebsd will install @node-rs/xxhash-freebsd-x64 instead of @node-rs/xxhash-darwin-arm64.

References

Closes npm/rfcs#612

[wraithgar]

Can you rebase your branch against latest? Testing matrix got updated for npm@10.

[wraithgar]

Once #6756 lands would you be willing to make a new PR to the release/v9 branch so that this new feature lands in npm 9?

[yukukotani]

@wraithgar It seems that already based on currnet latest branch. Backporting to v9 sounds nice!

$  git remote get-url origin 
https://github.com/npm/cli

$ git pull origin latest --rebase
From https://github.com/npm/cli
 * branch                latest     -> FETCH_HEAD
Current branch cpu-and-os is up to date.

$ git push
Everything up-to-date

[yukukotani]

I've rebased again

[yukukotani]

Does the test fail because it's just flaky or the diff may contain something wrong? It passed on my local machine

[wraithgar]

The test failed cause of an engines mismatch, we need to bump the config module's CI and engines. Disregard, and thank you for seeing this through the multiple modules it took to implement. I know a lot of folks would appreciate this landing in release/v9 if you're willing to make that PR too.

[yukukotani]

@wraithgar Sure, created #6776

[ryanblock]

@yukukotani (cc @wraithgar) this is rad! A question about intended behavior on this feature:

1. If an invalid arch and/or os flag is provided, no platform-specific dependencies are installed, and npm exits 0. I would consider that worthy of an error state; by exiting 0, we would lack the ability to know whether the command was malformed (perhaps due to typo, or by using x86_64 instead of x64, etc.). Was this intentional?

2. If a valid arch and/or os flag is provided, but the platform-specific dependency does not exist, nothing is installed and npm exits 0. I would also consider this an error state. If I am specifying os / arch to obtain a specific build of a native module, it should be assumed that the application that uses this dependency would be broken if that dependency isn't present. Was this intentional?

Thank you!

Tested with npm 10.2.3

[wraithgar]

Yes, this is intentional as all of these are optional dependencies, and missing an optional dependency is never an error state.

For 1, this is input validation which would need to happen in the config declaration. Off the top of my head I don't know what the valid set of parameters would be.

For 2, this is a job for npm query. We are planning on adding capabilities for it to exit 0 or 1 based on if there were or were not results, and that would address this kind of problem.