fix(plugin-pnpm): uses actual scope and name for hardlink package location

[UpstartMPotnick]

What's the problem this PR addresses?

The current implementation of the pnpm linker stores package hardlinks within a nested structure consisting of a hashed directory plus an arbitrary package directory. e.g. .store/lodash-npm-4.17.21-6382451519/package. The appended package path is a literal string in the PnpmLinker and (I assume) originated from the standard yarn|npm pack output filename.

Rarely, package internals might introspect the filesystem to apply some logic / constraints. Notably, Next.js has a specific check to guarantee modules are loaded relative to a next/ directory. This check fails because the hardlink exists inside of the package directory.

Conversely, when using pnpm directly, this check is successful because it places these hardlinks into a nested structure that includes the dependency name, e.g.:
.pnpm/next@14.2.14_react-dom@18.3.1_react@18.3.1/node_modules/next

Resolves #6269

How did you fix it?

This PR updates the getPackagePaths method to leverage the existing structUtils.stringifyIdent method to generate the nested hardlink directory instead of using the literal package string. This more closely aligns with the naming conventions of pnpm (and is also how the pnpm linker plugin behaves in Yarn v3).

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.

[arcanis]

Thanks! Can you also add a test for this behaviour?

[UpstartMPotnick]

Thanks! Can you also add a test for this behaviour?

Does it need a specific test? The location of the package seems to be an implementation detail; the literal path isn't itself tested, but there are existing integration tests (e.g. basic.test.ts) for each linker that already seem to validate the behavior. Likewise, the package install path for the pnp linker isn't directly tested either, as far as I can tell, but relies on the same integration tests.

[arcanis]

I think so; since your PR is intended to fix a specific obscure behaviour, having a test is quite important (otherwise noone will remember about it in a year time):

Rarely, package internals might introspect the filesystem to apply some logic / constraints. Notably, Next.js has a specific check to guarantee modules are loaded relative to a next/ directory. This check fails because the hardlink exists inside of the package directory.