npm install resolves bn.js to https://nr.staticblitz.com/bn.js and fails #2090

Describe the bug

In a WebContainer-based app host, npm install fails for dependency trees that include bn.js. During install, the package appears to be resolved as:

https://nr.staticblitz.com/bn.js

instead of being fetched as a normal npm package/tarball, and the request fails before a usable response is returned.

This looks like package-name resolution is misclassifying the dotted package name bn.js as a .js asset path rather than an npm package identifier.

What we observed

• The failure happens specifically for bn.js in a dependency tree during npm install.
• In Chrome DevTools, the failing request URL is:

https://nr.staticblitz.com/bn.js

• The request does not complete successfully and the package install fails.
• Related packages such as @types/bn.js do not show the same failure mode.
• Changing COEP/COOP settings was not the root cause. We initially suspected cross-origin isolation, but the issue persisted and the request URL itself appears wrong.

Expected behavior

bn.js should be resolved and installed like a normal npm package (for example from the npm registry / tarball), not rewritten to https://nr.staticblitz.com/bn.js.

Reproduction

I do not have a minimal public repro repo to attach right now, but the behavior is reproducible in our WebContainer-based app host when importing a project whose dependency graph includes bn.js (in our case via Polkadot-related dependencies).

A minimal repro should likely be possible with a package.json containing a dependency tree that pulls in bn.js and then running:

npm install

while observing the network requests made by the WebContainer runtime.

Workaround that succeeds

We worked around this by vendoring bn.js@5.2.2 locally inside the imported project and patching package.json to force npm to resolve it from a local file dependency instead of the broken remote resolution path:

{
  "overrides": {
    "bn.js": "file:./vendor/bn.js"
  }
}

with a local vendored package at:

vendor/bn.js/package.json
vendor/bn.js/lib/bn.js

Once we do this, install succeeds.

That strongly suggests the problem is not bn.js itself, but how WebContainer/StackBlitz resolves or fetches the package name bn.js.

Environment

• WebContainer API embedded in a custom app host
• Browser: Chrome
• Cross-origin isolation mode: credentialless (also tested while investigating with stricter settings; not the root cause)

Additional context

This matters because bn.js is a widely used transitive dependency in crypto / blockchain package trees, so this resolution bug breaks otherwise browser-compatible projects.