[BUG] npm ci respect the resolved url in package-lock.json #2004

ohardy · 2020-10-21T09:00:44Z

I use local verdaccio npm cache so I can fully work offline, do npm install offline etc, so my resolved field looks like:
"resolved": "http://localhost:4873/@babel%2fcore/-/core-7.12.3.tgz",

Current Behavior:

npm ci respect the resolved url in package-lock.json

Step 7/17 : RUN npm ci
 ---> Running in fd0eb4ace435
npm ERR! code ECONNREFUSED
npm ERR! syscall connect
npm ERR! errno ECONNREFUSED
npm ERR! FetchError: request to http://localhost:4873/yn/-/yn-3.1.1.tgz failed, reason: connect ECONNREFUSED 127.0.0.1:4873
npm ERR!     at ClientRequest.<anonymous> (/usr/local/lib/node_modules/npm/node_modules/minipass-fetch/lib/index.js:97:14)
npm ERR!     at ClientRequest.emit (events.js:315:20)
npm ERR!     at Socket.socketErrorListener (_http_client.js:469:9)
npm ERR!     at Socket.emit (events.js:327:22)
npm ERR!     at emitErrorNT (internal/streams/destroy.js:106:8)
npm ERR!     at emitErrorCloseNT (internal/streams/destroy.js:74:3)
npm ERR!     at processTicksAndRejections (internal/process/task_queues.js:80:21)
npm ERR!  FetchError: request to http://localhost:4873/yn/-/yn-3.1.1.tgz failed, reason: connect ECONNREFUSED 127.0.0.1:4873
npm ERR!     at ClientRequest.<anonymous> (/usr/local/lib/node_modules/npm/node_modules/minipass-fetch/lib/index.js:97:14)
npm ERR!     at ClientRequest.emit (events.js:315:20)
npm ERR!     at Socket.socketErrorListener (_http_client.js:469:9)
npm ERR!     at Socket.emit (events.js:327:22)
npm ERR!     at emitErrorNT (internal/streams/destroy.js:106:8)
npm ERR!     at emitErrorCloseNT (internal/streams/destroy.js:74:3)
npm ERR!     at processTicksAndRejections (internal/process/task_queues.js:80:21) {
npm ERR!   code: 'ECONNREFUSED',
npm ERR!   errno: 'ECONNREFUSED',
npm ERR!   syscall: 'connect',
npm ERR!   address: '127.0.0.1',
npm ERR!   port: 4873,
npm ERR!   type: 'system'
npm ERR! }

It looks like, the problem is because the error is ECONNREFUSED.
On my mac, with local verdaccio stopped, npm ci works well.

Expected Behavior:

Before npm 7, my CI is working well because npm ci ignoring this field.
With npm 7, npm ci respect this field and don't try another way to retrieve packages.

I think we should find a way to respect resolved field and try another way if the resolved field doesn't work.

Steps To Reproduce:

configure local npm registry
npm install
stop the local npm registry
in docker, run npm ci

Environment:

OS: Max OS 10.15.7
Node: 14.14.0
npm: 7.0.2
CI: Gitlab CI + docker runner

The text was updated successfully, but these errors were encountered:

wraithgar · 2021-07-01T18:54:02Z

Is this still a problem for you in the latest npm?

rodoabad · 2021-07-15T19:54:30Z

We're having similar issues where we have npm.foo.com for our internal registry which can resolve to bar.npm.foo.com or buz.npm.foo.com. When the package lock is using bar.npm.foo.com and bar.npm.foo.com is taken offline, it doesn't use npm.foo.com [so that it now resolves to buz.npm.foo.com] and generate a new lock file. It keeps trying to use bar.npm.foo.com like in the actual lock file.

The only solution is so delete package-lock.json and rebuild the lock file.

kleinen · 2021-07-15T19:58:29Z

My company has seen something similar. We have regional Artifactory servers that we use to for hosting a common npm registry. From a client perspective, there is a single registry and based on their IP, they will get redirected automatically to the appropriate regional server. Recently we retired one of these servers, which caused some of our projects to exhibit the same error signature mentioned in this issue.

The registry in the .npmrc is something similar to npm.company.com, but the pulled packages in the package-lock.json would have resolved fields similar to foo.artifactory.company.com. When we replaced foo.artifactory.company.com with bar.artifactory.company.com, npm ci freaks out because it can't reach foo.artifactory.company.com.

It would be good if npm had an option when running 'npm ci' to ignore the resolved URLs and use the configured registry.

@rodoabad You beat me to it. 😃

visheshd · 2021-07-26T06:53:52Z

Seeing this in 7.20.0 as well @wraithgar

clemensul · 2021-09-02T09:01:02Z

We have had this issue as well since migrating to npm v7.

For our local development, we use an SSH tunnel to reach our private registry. Hence the "tunnel"-URL (e.g. tunnel.private.registry.com:XXXX) is written to the package-lock.json.

When doing the build on our Jenkins server we can directly address the registry (private.registry.com) but npm only searches the package at the URL which is written to the package-lock.json.

Adding --registry=private.registry.com to npm i or npm ci does not help.

When we switch back to npm v6 it works without a problem, also with the package-lock format v2.

npm: '7.21.0',
node: '16.8.0'

witrin · 2021-11-14T12:17:03Z

Any schedule for this blocker?

thomas-girotto · 2022-01-12T08:06:33Z

Same problem: our CI agent is in azure and it must access our private registry with a different url than the one we use in local development. So the "resolved" url cannot be reached in CI.

Any plan to fix this issue ?

devminded · 2023-02-24T17:05:58Z

Ugly solution that may, or may not be good practice. 😬

jq 'walk(if type == "object" then with_entries(select(.key | test("resolved") | not)) else . end)' \
package-lock.json > package-lock.nuke.json \
&& cp package-lock.nuke.json package-lock.json

dev-trilobyte · 2023-06-15T13:29:09Z

years have gone with this bug without a fix so far. Any chance this gets fixed anytime?
Need to modify the package-lock every time is not really a "solution"

danielrotaermel · 2023-06-28T18:20:38Z

pnpm or yarn does not have such problems right? thinking about switching anyways

wraithgar · 2023-11-07T19:36:49Z

omit-lockfile-registry-resolved Was added as a solution to this problem. You can make lockfiles without a resolved entry so that they can be re-calculated at runtime in case you have constantly changing registry urls.

ohardy added Bug thing that needs fixing Needs Triage needs review for next steps Release 7.x work is associated with a specific npm 7 release labels Oct 21, 2020

This comment has been minimized.

Sign in to view

ruyadorno removed the Needs Triage needs review for next steps label Jan 5, 2021

wraithgar closed this as completed Nov 7, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[BUG] npm ci respect the resolved url in package-lock.json #2004

[BUG] npm ci respect the resolved url in package-lock.json #2004

ohardy commented Oct 21, 2020 •

edited

This comment has been minimized.

wraithgar commented Jul 1, 2021

rodoabad commented Jul 15, 2021 •

edited

kleinen commented Jul 15, 2021 •

edited

visheshd commented Jul 26, 2021 •

edited

clemensul commented Sep 2, 2021

witrin commented Nov 14, 2021

thomas-girotto commented Jan 12, 2022

devminded commented Feb 24, 2023

dev-trilobyte commented Jun 15, 2023

danielrotaermel commented Jun 28, 2023

wraithgar commented Nov 7, 2023

[BUG] npm ci respect the resolved url in package-lock.json #2004

[BUG] npm ci respect the resolved url in package-lock.json #2004

Comments

ohardy commented Oct 21, 2020 • edited

Current Behavior:

Expected Behavior:

Steps To Reproduce:

Environment:

This comment has been minimized.

wraithgar commented Jul 1, 2021

rodoabad commented Jul 15, 2021 • edited

kleinen commented Jul 15, 2021 • edited

visheshd commented Jul 26, 2021 • edited

clemensul commented Sep 2, 2021

witrin commented Nov 14, 2021

thomas-girotto commented Jan 12, 2022

devminded commented Feb 24, 2023

dev-trilobyte commented Jun 15, 2023

danielrotaermel commented Jun 28, 2023

wraithgar commented Nov 7, 2023

ohardy commented Oct 21, 2020 •

edited

rodoabad commented Jul 15, 2021 •

edited

kleinen commented Jul 15, 2021 •

edited

visheshd commented Jul 26, 2021 •

edited