NPM virtual registries: cached metadata responses and Dedicated

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

  • Close this issue

🔥 Problem

When the NPM virtual registry caches a metadata response, it will replace all urls found in the response from the upstream. Basically, instead of pointing to the upstream, we need to point to the virtual registry which lives in the GitLab instance.

This works as expected. The problem is that on Dedicated, there is a common ask to update the name of the instance or the host of the instance. Updating that host will render all links used in the metadata cache entry invalid because the point to the older name/host.

🚒 Solution

There is not much we can automate here. So, the only way to mitigate this problem is to document what to do when a Dedicated instance updates the name/host.

We will need to require that the NPM upstream caches to be reset. This way we start over and with time, the metadata responses will populate with the correct urls.

A possible alternative is to only reset the metadata information in the upstream caches. This depends if we have a way to flag which type of data is in cache (package file vs metadata). If we have that, then we can implement a reset action for metadata caches only.

⚔️ Wild Idea ™️

Could we automatically detect the name/host change and reset the metadata cache used in NPM virtual registries? 🤔

Edited Aug 14, 2025 by 🤖 GitLab Bot 🤖
Assignee Loading
Time tracking Loading