NPM packages not following the naming convention should not block project transfers
🔥 Problem
Some historic context first. When the npm Registry was released, it has been decided to enforce the naming convention on all packages.
As such, when transferring a project to a different group, a check was implemented: if the project had npm packages and the root group is changed, the transfer is rejected. That was because existing npm packages would not be valid anymore due to the enforced naming convention.
Later, at some point, we lifted the naming convention for the project level endpoints: the users were free to use whatever package names they wanted (including scopeless packages).
The problem is that the project transfer service check stayed the same. Guess what happens if a project with scopeless or any package name is transferred to a different group (in a way that the root group is changed)? Yes,
🚒 Solution
- Update the project transfer service check so that only NPM packages with the naming convention are considered.
- Update specs to assert that we can transfer a project with:
- NPM packages that do not follow the naming convention (package scope is different that the root group path). or
- scopeless NPM packages.
☔ Workaround
The only possible workaround to unblock the project transfer is:
- Delete all NPM packages.
- Wait at least 24 hours. To avoid running into #370834 (closed).
- Transfer the project.
- Re publish all NPM packages.
This might not be an acceptable workaround in all situations.