-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Description
When installing a dependency, or working with a project without pnpm, without a lockfile, or from a template, unless that package.json has the exact latest version selector for that dependency, or has a static version of the dependency specified, an older, version of that dependency will be installed, meaning that buggy, stale, feature-lacking or security-compromised versions of a dependency are likely to be installed.
This means that maintaining a template becomes exceptionally arduous and maintenance intensive. It also means attempting to work with a project which has no pnpm lockfile (such as a project whose dependencies were previously managed with npm or yarn) is exceptionally prone to having outdated dependencies, which will cause the issues with outdated packages listed above.
The default behaviour should be the previous behaviour, with a configuration option to change that to the less desirable (imho) behaviour. It's hard to understand the reason for these new defaults, and a lot of quite serious problems (and spurious bug reports on OSS projects) are likely to arise as a result.
As a real world example, we encourage creation of a new svelte project with:
npx init svelte@latest which would result in getting the dependency @sveltejs/kit@1.5.0 due to the specifier "@sveltejs/kit": "^1.5.0". This version is quite old, has unresolved bugs, security issues, and lacks features we now document, but having this minimum pinned has been fine up until now, because pnpm <8 and other package managers will install the latest version by default.
Last pnpm version that worked:
v7.x.x
pnpm version:
v8.x.x
Code to reproduce the issue:
none
Expected behavior:
installing a dependency, by default, uses the latest matching version of that dependency.
Actual behavior:
installing a dependency, by default, uses the lowest matching version of that dependency.
Additional information:
This works as the docs describe, but this functionality feels like a regression because of the stark difference to how you would expect pnpm to manage dependencies, as well as how other equivalent tools manage dependencies.
Further to this, I couldn't fathom the reason for this change. Is there some missing context?