<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=344107) </details> <!--IssueSummary end--> ## :fire: Problem As stated in https://github.com/npm/registry/blob/master/docs/responses/package-metadata.md, the NPM metadata endpoint can return json response of two types: 1. Full. All available fields are returned. 1. Abbreviated. Only a handful set of fields are returned. They are actually those need by `$ npm install` In https://gitlab.com/gitlab-org/gitlab/-/issues/330929, we decided to return the Abbreviated form all the times to fix the given ~bug at hand and at the same time not introduce a ~performance issue. ## :fire_engine: Solution Read the `accept` http header sent by clients and select the Full or Abbreviated form accordingly. ## :octagonal_sign: Blocked by Sending the full metadata json document for each version of a given NPM package can be problematic as some NPM packages have thousands of versions. This could lead to giantic body responses. This situation is not unique at GitLab. Here is the full metadata of the `npm` package on npmjs.org: https://registry.npmjs.org/npm. Yes, that's over 15MB :scream_cat: To counter this situation, we will need https://gitlab.com/gitlab-org/gitlab/-/issues/338485. A background job can help as it has more time to generate both types of metadata and store them in object storage. Then, on the metadata endpoint, it's just a question to select the proper type and send a redirect to the file on object storage.