fix: Reject dependency names with leading/trailing whitespace (fixes duplicate installs)

[muskaanshraogi]

What's the problem this PR addresses?

Yarn currently accepts dependency names with leading or trailing whitespace in package.json. For example:

{
  "dependencies": {
    "lodash": "^4.17.21",
    "lodash ": "^4.17.20"
  }
}

Closes #7099

How did you fix it?

The fix introduces validation at the manifest parsing stage to reject dependency names with leading or trailing whitespace.

Checklist

• I have read the Contributing Guide.

• I have set the packages that need to be released for my changes to be effective.

• I will check that all automated PR checks pass before the PR gets reviewed.

[clemyan]

I think there are stuff that can support package names with trailing whitespace? (e.g. workspace: dependencies) That could be confusing though, so I think it's fine to just not allow them.

But the root cause of #7099 is that when deciding what URL to call on the npm registry we just plop the package scope and names into new URL (which strips trailing whitespace). So the problem is more than just trailing whitespace.

The npm docs does list some restriction on package names:

• The name must be less than or equal to 214 characters. This includes the scope for scoped packages.
• The names of scoped packages can begin with a dot or an underscore. This is not permitted without a scope.
• New packages must not have uppercase letters in the name.
• The name ends up being part of a URL, an argument on the command line, and a folder name. Therefore, the name can't contain any non-URL-safe characters.

Theoretically, a custom registry can allow these rules to be violated, allowing packages with names containing non-URL-safe character to resolve (by accepting urlencoded package names in URLs). But looks like npm (the cli) does not support them either?

All of that is to say, while I think this solution is fine, I do think I would be better to either

• urlencode the package name in URLs in the plugin-npm resolvers and fetchers and just let the registry return an error on those; or
• enforce the above rules on the plugin-npm resolvers and fetchers level instead of in the core.

[muskaanshraogi]

I see. I’ve updated the approach to encode the package name when building URLs at the plugin-npm level , so the exact identifier is sent and the registry can handle invalid cases correctly.