npm i / npm ci for multiple target archs

[samskiter]

I can't find any documentation on the --target-arch and --target-platform arguments to npm install and npm ci. I'd like to install my node modules for multiple platforms and architectures and then distribute that node_modules folder (see this blog for some of the motivation).

Is that possible in a single command? if not several? if several, how would I know if files had been overwritten? How could I confirm the state of my node_modules is correct?

Does npm ci support target arch/platform? can I specify many at the same time?

[samskiter]

Just bumping this up - I don't think I'm asking for any code here, just some clarification of documentation / some advice please?

@MylesBorins sorry to tag - is there anyone you know who might be able to answer this question please?

[nlf]

--target-arch and --target-platform are not flags supported by npm at all, did you see them referenced somewhere? in addition to that, native addons compiled by the likes of node-gyp often create the same output file regardless of arch and platform, so installing multiple arches and platforms into one node_modules directory may not be possible at all.

are you building a package that you want to distribute binaries for, or just trying to package up your project that is building third party packages?

[samskiter]

Here is where I found those arguments referenced: https://stackoverflow.com/questions/24961623/installing-node-js-packages-for-different-architecture

[darcyclarke]

@samskiter I think the article you referenced actually gets a number of things wrong. Checking in your node_modules folder will not ensure that your project/application will work across different architectures/platforms. We do a best effort to install dependencies but there are a number of conditions which may mean npm install does not make the same node_modules across different platforms/architectures.

Example: npm will actually fail to install optional dependencies if their supported os (process.platform) or cpu (ie. process.arch) definitions mismatch the current platforms/environment (this is why they're considered optional & we do a best effort in all cases). engines (ref. https://docs.npmjs.com/cli/v8/configuring-npm/package-json#engines) will also fail when --engines-strict is set (ref. https://docs.npmjs.com/cli/v8/using-npm/config#engine-strict).

Although not recommended, many package maintainers also use postinstall scripts which can add/edit/delete the files you may end up seeing on disk between environments.

With this in mind, & for the best results, it makes sense to run npm install on the exact same architecture/environment you expect to leverage the generated node_modules again elsewhere (ex. run inside a Docker instance that maps to whatever your ci/staging/production env is expected to be). If you use a strategy like this then you shouldn't have problems.

That said, if you run npm ci it will actually blow away anything in your node_modules & only leverages the lockfile as a source-of-truth (ref. https://docs.npmjs.com/cli/v8/commands/npm-ci). If you're trying to reuse/check-in your node_modules folder then you'll want to stick with npm install vs. flip-flop between the two.

As per @nlf's note, --target-arch & --target-platform are options used by the @mapbox/node-pre-gyp project not npm itself. If you're looking to build platform specific binaries for your project that's a bit different then being a consumer of packages which should be generating platform specific files/binaries (ex. using the postinstall strategy referenced above). Likely, you'll want to look through node-pre-gyps docs

[samskiter]

Thanks for your reply! It sounds like this is something that is nearly supported - e.g. I can pass those options to node-pre-gyp and nearly get what I want - is there any chance I could make a feature request for more formal support of this?

[samskiter]

Here's a SO post that references those arguments in use to npm i (albeit with the prerequisite that node-pre-gyp is being used)

[kroese]

It seems npm install has a --cpu flag. I dont know if this was added very recently, but it should do exactly what you want? Install the packages for the specified architecture.