You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
pnpm i @bazel/typescript (a few days ago when it was deprecated)
then pnpm i @bazel/typescript now that the deprecation message got removed
Expected behavior:
The package was deprecated, then I published another version of it and npm no longer says that it's deprecated.
I would expect the lockfile to be unaffected by random changes from npm.
Actual behavior:
This causes the lockfile to be out-of-date if pnpm i:
$ git diff pnpm-lock.yaml
diff --git a/pnpm-lock.yaml b/pnpm-lock.yaml
index 0db7f9c15..8575c33c7 100644
--- a/pnpm-lock.yaml
+++ b/pnpm-lock.yaml
@@ -1275,7 +1275,6 @@ packages:
id: registry.npmjs.org/@bazel/typescript/5.5.1
name: '@bazel/typescript'
version: 5.5.1
- deprecated: This package is from build_bazel_rules_nodejs which is no longer maintained. Consider using https://github.com/aspect-build/rules_ts instead.
hasBin: true
requiresBuild: true
peerDependencies:
Since npm doesn't have an immutability guarantee for this property of a package, I don't think it ought to appear in the lockfile. Is there some reason that copying the deprecation message into the lockfile is useful?
The text was updated successfully, but these errors were encountered:
There are two reasons. One of the reasons is that on code reviews you can see deprecated packages.
The second reason is that when the lockfile is up-to-date, pnpm doesn't make requests to the server to download the metadata. So the only way to know if a package is deprecated is to store this info in the lockfile.
pnpm version:
7.17.1
Code to reproduce the issue:
pnpm i @bazel/typescript
(a few days ago when it was deprecated)then
pnpm i @bazel/typescript
now that the deprecation message got removedExpected behavior:
The package was deprecated, then I published another version of it and npm no longer says that it's deprecated.
I would expect the lockfile to be unaffected by random changes from npm.
Actual behavior:
This causes the lockfile to be out-of-date if
pnpm i
:Since npm doesn't have an immutability guarantee for this property of a package, I don't think it ought to appear in the lockfile. Is there some reason that copying the deprecation message into the lockfile is useful?
The text was updated successfully, but these errors were encountered: