npm ci fails offline: onnxruntime-node postinstall fetches CUDA/TensorRT binaries from api.nuget.org by default

[pinecone-groundskeeper]

Problem

onnxruntime-node (currently resolved to 1.27.0 via the ^1.15.0 range in
package.json) runs a postinstall script (node ./script/install) that, on
linux/x64, unconditionally attempts to download the CUDA/TensorRT execution
provider binaries (libonnxruntime_providers_cuda.so,
libonnxruntime_providers_tensorrt.so, libonnxruntime_providers_shared.so)
from a NuGet feed at `(api.nuget.org/redacted) — unless the
installer is explicitly told to skip.

This is driven by script/install-metadata.js in the installed package, which
hardcodes:

requirements: {
  'linux/x64': ['cuda12'],
  ...
}

script/install.js only skips this download if ONNXRUNTIME_NODE_INSTALL (or
the npm config equivalent) is explicitly set to skip — there is no such
opt-out configured anywhere in this repo (no .npmrc, no env var). If the
NuGet feed is unreachable — any network-restricted CI runner, corporate proxy,
sandboxed/offline environment, or Docker build with locked-down egress — the
download throws and npm ci/npm install fails outright with:

npm error Error: getaddrinfo EAI_AGAIN api.nuget.org
npm error path .../node_modules/onnxruntime-node
npm error command sh -c node ./script/install

Reproduced on a clean checkout: npm ci fails with the error above. Setting
ONNXRUNTIME_NODE_INSTALL=skip npm ci succeeds cleanly (385 packages
installed, 0 vulnerabilities), and with that skip in place npm run typecheck, npm test (23/23 passing), npm run lint, and npm run format:check all pass without issue — confirming the project only needs the
bundled CPU execution provider. Nothing in src/ configures or uses a CUDA
execution provider; src/embeddings.ts runs @huggingface/transformers with
the default (CPU) backend.

This doesn't currently break this repo's own CI (ubuntu-latest
GitHub-hosted runners have unrestricted internet access to nuget.org), but it
makes npm install fragile for anyone following the README's npm install
step from a network-restricted environment — exactly the kind of place a
"just clone and run this example" tutorial gets used (corporate networks,
egress-locked CI, offline dev containers).

Acceptance criteria

• Adding an .npmrc entry (or equivalent) that sets the package-specific
  onnxruntime-node:onnxruntime_node_install=skip config so a clean
  npm ci/npm install no longer attempts to contact api.nuget.org.
• npm ci succeeds on a clean checkout with no other environment variables
  set.
• npm run typecheck, npm test, npm run lint, and npm run format:check
  all still pass after the change (they exercise only the CPU embedding path,
  so behavior should be unaffected).

Scope

Only the onnxruntime-node postinstall CUDA-download behavior is in scope —
add the minimal config needed to opt out of the unused GPU binary fetch.
Do not touch unrelated dependency versions, CI workflow content, or any other
package's install behavior; those are tracked separately.

Generated by GitHub Maintenance Audit · sonnet50 · 104 AIC · ⌖ 5.93 AIC · ⊞ 7.9K · ◷

[pinecone-groundskeeper]

I reproduced this: a clean npm ci against the current lockfile (onnxruntime-node@1.27.0) fails offline with getaddrinfo EAI_AGAIN api.nuget.org, exactly as described.

I also verified the fix mechanics against onnxruntime-node@1.27.0's actual install scripts (script/install.js / script/install-utils.js) and against the npm version this environment resolves with (npm 10.9.8), and found one correction worth flagging before someone lands this:

The .npmrc syntax in the acceptance criteria doesn't actually take effect. onnxruntime-node:onnxruntime_node_install=skip (the package-scoped <pkg>:<key> form) is accepted by npm config get, but it is not propagated to the dependency's postinstall script as an npm_config_* env var — I confirmed this empirically: with only that scoped entry in .npmrc, npm install in a throwaway project still attempted the NuGet download and failed offline.

The form that actually works is the plain, unscoped key:

onnxruntime_node_install=skip

This does get passed through to lifecycle scripts as npm_config_onnxruntime_node_install=skip, which onnxruntime-node's parseInstallFlag() reads directly (js/node/script/install-utils.js in microsoft/onnxruntime, tag v1.27.0) and correctly short-circuits the CUDA/TensorRT download. I verified this in an isolated test project: with that plain key in .npmrc, npm install onnxruntime-node@1.27.0 succeeds in ~2s with no network call to api.nuget.org, versus failing with the scoped-key version.

Why I'm not opening a PR myself: the actual code fix is a one-line .npmrc addition, but the sandbox this Fixer run executes in blocks writes to .npmrc specifically (treated as a sensitive file — presumably because it's a registry/auth/proxy configuration surface), regardless of which tool I use to write it. That's a tooling limitation of this automated environment, not an ambiguity in the fix itself, so I'm routing it to a human rather than finding a workaround.

Suggested change — add .npmrc at the repo root:

onnxruntime_node_install=skip

with a short comment noting why (unused CUDA/TensorRT binaries, breaks offline installs otherwise). After adding it, a clean npm ci should succeed with no other env vars set, and npm run typecheck/npm test/npm run lint/npm run format:check should all be unaffected (they only exercise the CPU embedding path).

Generated by GitHub Maintenance Fixer · sonnet50 · 92.6 AIC · ⌖ 8.41 AIC · ⊞ 9.4K · ◷