NPM packages not following the naming convention should not block group path updates
🔥 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 updating the group path, a check was implemented. Basically, it says:
- if the group has the
packages
features and - the group is receiving a path update and
- has npm packages
Then, the group path update 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 group update service checks stayed the same. Guess what happens if a group with scopeless or any package name sees its path updated? Yes,
🚒 Solution
Update the check to do the following:
- Allow the update if the group has a parent (eg. subgroups don't play a role into namespaced NPM packages).
- check for scoped npm packages (the scope has to be the group path).