NPM Registry Endpoint Response Lacks Package Dependency Metadata; Breaks NPM

Summary

The response exposed by the GitLab NPM Registry API endpoint (https://gitlab.com/api/v4/packages/npm/@my-group%2fmy-project) lacks metadata JSON keys from package.json. Specifically lack of dependencies, devDependencies, etc. causes npm install @my-gitlab-group/my-package to fail dependency resolution on the FIRST npm install. Subsequent npm install commands appear to parse the package.json extracted from the tarball of the initial npm install.

Steps to reproduce

1. Create a root GitLab.com group (meaning gitlab.com/your-group-here)
2. Create a project/repository under that group: gitlab.com/your-group-here/your-project-here
3. Be sure NPM Registry is accessible (feature is enabled for all on GitLab.com but requires >= Gold plan for access to the feature)
4. Create your package with at least one dependency: npm init && npm install --keep mkdirp
5. Following the GitLab NPM Registry documentation directions, npm publish your package to your GitLab project's registry
6. Include your project's package as a dependency in some test package.json OR run npm install @your-group-here/your-project-here
7. Examine package-lock.json noting that for your project's package name, only version, resolved and integrity keys exist!
8. Run npm install a second time while the package-lock.json still exists and note this time the dependencies, devDependencies, etc. are all populated!

Example Project

I couldn't find a public GitLab project with a NPM registry to show as an example. We only have private packages in our organization/group otherwise I would create an example one there for reference from this issue.

What is the current bug behavior?

npm install for a GitLab NPM registry hosted package fails on a fresh install (no package-lock.json)!

What is the expected correct behavior?

npm install should work on a fresh install.

Relevant logs and/or screenshots

My speculation is that npm install needs additional metadata in the HTTP response from the NPM registry for initial installs to traverse dependencies and install those.

If you compare the response of the GitLab NPM registry endpoint: https://gitlab.com/api/v4/packages/npm/@my-group%2fmy-project to the official NPM registry (using package mkdirp as an example): https://registry.npmjs.org/mkdirp

Note the plethora of additional metadata included in the response. Specifically: under a given version number key, GitLab appears to ONLY include name, version, dist (and even then, dist only contains shasum and tarball).

If you want to examine the response JSON version key structure more closely and have curl and jq installed, try: curl -s https://registry.npmjs.org/mkdirp | jq '.versions."0.5.1"'

Specifically, I believe npm install is looking for dependencies, devDependencies, etc. in the response to also install those in the same atomic npm install command. Without that metadata, a second npm install is required on a fresh install until package-lock.json exits.

Output of checks

This bug happens on GitLab.com

Results of GitLab environment info

This bug happens on GitLab.com

Results of GitLab application Check

This bug happens on GitLab.com

Possible fixes

A possible workaround right now is simply to execute the install twice: npm install && npm install. Pretty lame and not acceptable or scalable to our entire team, CI pipelines, etc. from my organization's perspective. 📉