Lift the NPM package naming convention for the project level API

Release post

When publishing npm packages to your project's registry, you have had to name your package with @scope/package-name, where the scope must exactly match the root namespace of your project, including the case. For many of you, this meant using a capital letter. However, npmjs.com does not allow capital letters in the scope. So, you were forced to either change your group name, which may have several unintended side effects or to not use the GitLab Package Registry.

Moving forward, we will no longer enforce this naming convention for the project-level endpoint. Huzzah. Now you can name your packages and scope whatever you want. Hopefully, this makes using GitLab and npmjs.com a little bit easier to use.

It's worth noting that using the instance-level endpoint will still require you to use the exact (case sensitive) root of your namespace as @scope.

Problem to solve

Our current npm API enforces a naming convention. This naming convention has some problems as it is too restrictive to some users or self-managed instances.

The implementation has been done before my time but I think that the naming convention is mainly used to locate the proper package when hitting the instance level API. Basically, the backend receives: hey, I need package X and that's it, no group id, no project id. With the only information of the package name, the backend has to accurately locate the package within all projects accessible for the current user.

This naming convention is implemented as a model validator, which means that before a npm package is saved to the database, the package name has to be conform to the naming convention, which means that all npm packages need to be ok with that convention.

Proposal

Use the same approach as we have in the Maven API:

• At the Project level
  • Don't impose any naming restriction. Users are free to use whatever they want, including not using an @scope at all.
• At the Instance level
  • Similar to maven, only the packages that follow the naming convention are exposed via this API level.
  • If a package doesn't follow the naming convention, it can't be retrieved with the instance level API.

Other considerations

If one day, we ever implement the Group level API, I think we can follow again what we have for the Maven api:

• At the Group level
  • Don't impose any naming convention
  • What about duplicated package names? Use the same strategy as on the Maven API:

The group level endpoint works with any package names, which means the you have the flexibility of naming compared to instance level endpoint. However, GitLab will not guarantee the uniqueness of the package names within the group. You can have two projects with the same package name and package version. As a result, GitLab will serve whichever one is more recent.

Work complexity

It should be quite low as we "only" have:

• remove the model validator
• make sure that the instance level API locate the package using the naming convention (should be already the case, so nothing to do).
• make sure that the project level API works with any package name (rspec example)
• make sure that the instance level API works with only package names that follow the naming convention (rspec example)