New version of npm install on DevOps Pipeline is failing due to a bad hostname, but it never used to with previous version

Viewed 126

We've recently had an Azure DevOps Pipeline start throwing errors at the npm install step, with the error being:

getaddrinfo ENOTFOUND proget.websilk.local

This makes sense, as that address is not a real domain name and I assume at some point, we were using a local npm repository (websilk is the name of an agency we used to use many years ago).

However, we never have experienced this error before. We have noted that the images used on the build servers for DevOps have upgraded the version of npm from 6.14.15 to 8.1.0 since our last deployment (https://github.com/actions/virtual-environments/blob/win19/20211229.2/images/win/Windows2019-Readme.md).

So something in the new version of npm is doing something differently than our previous installs. It makes sense that it would fail on the URL in question, but why hasn't our previous installs failed with that same error? The hostname is only present in package-lock.json under the resolved property. I tried reading up on what this does, but it's not entirely clear to me (it sounds like it is noting where that package came from, but i'm not clear on why it is being referred to by npm install).

Perhaps these have always been failing and the previous version just ignores them? I did a npm install locally with version 6.14.15 and saw no references to that hostname, and those packages were successfully installed, so it never referenced the invalid hostname.

0 Answers
Related