[flipp3r]

> This really annoys me, but what can one do? At least it's fixed now.

Install your own repository manager? This is the standard in every company I've worked for so far, at least in the Java world. Artifactory supports NPM, so set it up as a proxy.

[akatechis]

We use ProGet with npm, docker and nuget feeds. We only ever hit the internet when we install fresh dependencies. After that, they get cached on our local service for all developers and machines to consume. That, coupled with yarn itself, which caches dependencies locally as well so subsequent installs don't even go out to the network, has accelerated our build times considerably.

[bartread]

That's interesting - thanks. Of course, it has a price tag, but so does the rest of our pipeline, along with our time.

[PebblesHD]

As far as the monetary price of implementing such a system, Nexus OSS[1] also supports NPM proxying and is free for basic usage.

[1] - https://www.sonatype.com/nexus-repository-oss

[zamber]

We have Nexus in a subnet for faster installing. We had to write scripts porting over lockfiles from npm to nexus and back.

This had to be added to a precommit hook to not break CI. Seriously, package.json should allow to specify what endpoints should be used if available in a given order. Now it's up to each dev team to handle.

My main concern is that it's brittle. Nexus caches exact versions and nothing more so we don't even have assurance that it will work nicely when NPM goes down.

On the other hand lockfiles are awesome. I missed them back in 2012... copying over node_modules on USB drives was not cool.

[acejam]

You can specify what registry to use with a simple project-based .npmrc file. We have ours point to our Nexus npm proxy.

[zamber]

That's what we eventually do but the lockfiles don't care, a resource url is a resource url. We use yarn too which does proxies only in .yarnrc IIRC.

Do you have an externally available Nexus? Using ours through a VPN beats the main purpose - fast(er) installs. That's why for WFH scenarios we have a script to switch between our proxy and NPM.

[acejam]

Our Nexus setup is internal only. For WFH, we have hundreds of folks using a corporate VPN which routes to our office, and then our office routes to our AWS VPC, which is where our Nexus installation lives. I set this configuration up and haven't had any real issues with it, nor do I see any reason to switch between a proxy and npm.

If a developer is using an older buggy version of npm that doesn't respect .npmrc and changes a lock file to point back to npmjs.org entries, we deny the PR and ask for it to be fixed. Right now that check is unfortunately manual, but there are plans to automate it. It can be easy to miss at times though, since GitHub often collapses lock files on PR's due to their size.

For us, the main purpose of using Nexus as a proxy is to maintain availability and to cache/maintain package versions. If you're using Nexus to make things faster, then you probably shouldn't be using it. If you want faster installs, look into using `npm ci`.

[solatic]

Nexus OSS can't be clustered / put in a highly-available install, which is a paid feature for Nexus.

To ensure that you're actually deriving benefit from your Nexus install, you have to block outbound connections to the NPM public registry from your CI build agents (if you don't firewall it off, you don't want to wake up one day and find that both origin and the proxy are erroring because your proxy never actually cached anything and you never tested tested your proxy... right?), with only the Nexus installation permitted to make such outbound connections. And as bad as NPM may be, there are real maintenance costs to running your own Nexus install (not least of which, managing updates that will take Nexus down and communicating them with your dev team so that CI builds which error out when Nexus is down can be restarted when it goes back up), and thinking that you can do better than NPM is hubris. Running a private Nexus OSS install for the purpose of trying to increase availability for low cost (not zero - you still have to pay the infrastructure costs) is usually a false economy.

If you work for a company with enough operations and infrastructure resources that adding a clustered install is trivial, then you probably have enough resources to pay for an Artifactory license.

TL:DR - NPM has its faults but it's still probably de-facto both more available and better updated than taking on the responsibility of running a proxy unless you have mature ops/infra teams

[actionowl]

This one is free, we use it and it works for our needs. We also have it integrated with our Active Directory: https://www.verdaccio.org/

[grumblestumble]

We use Verdaccio and I can't imagine any serious dev shop not using some kind of proxy / private registry for NPM packages. It's really simple to set up and has served us well, aside from minor hiccups.

[madeofpalk]

Sinopia was used at a previous job https://github.com/rlidwka/sinopia

[jasonjayr]

Just to save other users some time, it seems like sinopia is no longer maintained, and doesn't work on Node 8

https://github.com/rlidwka/sinopia/issues/456

Verdaccio, mentioned in a sibling comment seems to be the recommended replacement ...

https://github.com/verdaccio/verdaccio

[achamayou]

The OSS edition of Nexus supports npm proxies. Sure there’s a little bit of setup, but it will more than pay for itself the first time an event like this one occurs.

[acejam]

Agreed. It's very easy to setup a private npm registry using Nexus OSS.