1.) Make sure you are using `npm ci` instead of `npm install`. The `ci` install command is often much faster and skips a lot of stuff that `install` does. It's also better at sticking purely to your package-lock.json versions. I suggested on UserVoice at one point that Azure Pipelines should switch to `npm ci` as the npm task default. `npm ci` is a relatively recent npm command and I don't everyone has caught on to it yet.
2.) You can use Azure Artifacts for NPM packages. It acts as an alternate NPM feed and caches packages to your Azure DevOps account. Artifacts only supports NPM and NuGet, so it isn't a general caching solution, but in this specific case it helps. I've noticed the builds I have using Artifacts are a bit faster than going straight to NPM. (I started using Artifacts for private NPM packages, so I'm not using it in every build yet.) The current biggest caveat to using Artifacts as your main NPM feed for a project is that it doesn't support NPM audits currently. (I also made sure to report that on UserVoice.)
Like I said, caching is only a useful side effect of Artifacts for npm and NuGet users (that have access to Artifacts). I would believe/hope that Microsoft may still have interest in adding proper caching to Azure Pipelines directly.
Making this decision is bad enough, but making it because you've chosen a bad CI/CD stack is even worse. Use the tools that work, instead of breaking things to match.
Are you talking about Azure Artifacts? Like I said, I'm using Azure Artifacts as a Private NPM repository for proprietary packages. It also providing caching benefits was a pleasant surprise.
For my projects using Artifacts as their NPM repository, they use an .npmrc at the repository top level to only use that feed (and its pass through capability to the public feed), so for those projects it is the same stack from dev through to production. As I said, the one caveat is that if I need to `npm audit` (which is generally a good idea) I currently have to redirect to the main public NPM feed. Other than that it is a solid replacement NPM feed.
I can't find an actual issue and again as I mentioned in the post, replacing my AWS instance with a new AWS instance also eventually hit the same issue. Maybe it's some perfect storm of problems but that is just more speculation.
The single issue I agree with is the lack of caching - installing NPM packages can take up to 15 minutes in the worst case. MS have known about this for years, so I honestly don't understand why they haven't done something about it.
I also think the hosted build machines are underpowered, despite their claims of Xeon CPUs - build on even an Azure B1ms VM (a low-powered, burstable SKU) are up to 3 times faster. In fact this is how we solve the NPM caching and performance issues - by running the VSTS Build Agent (it's OSS!) on relatively cheap Azure VMs.
Aside from these niggles though, I actually think the Azure DevOps product is fantastic.