I've been working on migrating a very large monorepo from Yarn v1 to PNPM. The ability to use --filter to only install dependencies for a subset of the repository is an absolutely huge deal for us both for local development and on CI 🙇 .
One of the things I've noticed while working on this is that pnpn-lock.yaml file seems to "flicker", for lack for a better description. I periodically have to regenerate the lockfile by deleting it and running pnpm install from the root of the repository (no --filter). Several commits later after running pnpm install --filter <specific package> I'll get seemingly unrelated changes to pnpm-lock.yaml that look like this:
@@ -50616,6 +50618,7 @@ packages:
hasBin: true
resolution:
integrity: sha1-T4B9l2FrV9o62olo0ylTOwjkPaE=
+ tarball: '@monorepolint/cli/-/cli-0.5.0-alpha.19.tgz'
/@monorepolint/core/0.5.0-alpha.40:
dependencies:
'@monorepolint/utils': 0.5.0-alpha.40
@@ -50626,6 +50629,7 @@ packages:
tslib: 1.13.0
resolution:
integrity: sha1-3c8lN62Qokybl04urGlGKpXqO/U=
+ tarball: '@monorepolint/core/-/core-0.5.0-alpha.40.tgz'
/@monorepolint/rules/0.5.0-alpha.40:
dependencies:
'@monorepolint/core': 0.5.0-alpha.40
@@ -50637,11 +50641,13 @@ packages:
semver: 6.3.0
resolution:
integrity: sha1-Eq1cri97tJf71ZecDyFgNOL5IMs=
+ tarball: '@monorepolint/rules/-/rules-0.5.0-alpha.40.tgz'
/@monorepolint/utils/0.5.0-alpha.40:
dependencies:
glob: 7.1.6
resolution:
integrity: sha1-oaHIYGxRitvngIpET8O0waB9z20=
+ tarball: '@monorepolint/utils/-/utils-0.5.0-alpha.40.tgz'
It seems to happen pretty consistently with the tarball key and I'm pretty confident those are unrelated to what I actually changed in package.json. I've seen other keys flicker like this where I'm less confident that they're unrelated (dev and optionalDependencies).
My completely unsubstantiated hunch is that this is somehow being caused by toggling between running pnpm install for the entire repository and for subsets of the repo by using --filter.
pnpm version: 5.8.0
Code to reproduce the issue:
I don't have a concise repro for this yet. If it's helpful I can try and put something together, but it'll probably be a little contrived.
Expected behavior:
In a perfect world the lockfile would be stable, and changes would be (relatively) easy to explain by looking at the corresponding changes to package.json files. We actually use subsets of the lockfile as cache key inputs for out build tool, so flickering like this triggers unnecessary recompilation. Aside from that, though I'm worried about confusion during code reviews (years of yarn has taught us to review changes to the lockfile since they can have wide impact).
Actual behavior:
The lockfile "flickers" as described above.
Additional information:
node -v prints: v10.16.3
- Windows, OS X, or Linux?: OS X
I've been working on migrating a very large monorepo from Yarn v1 to PNPM. The ability to use
--filterto only install dependencies for a subset of the repository is an absolutely huge deal for us both for local development and on CI 🙇 .One of the things I've noticed while working on this is that
pnpn-lock.yamlfile seems to "flicker", for lack for a better description. I periodically have to regenerate the lockfile by deleting it and runningpnpm installfrom the root of the repository (no--filter). Several commits later after runningpnpm install --filter <specific package>I'll get seemingly unrelated changes topnpm-lock.yamlthat look like this:It seems to happen pretty consistently with the
tarballkey and I'm pretty confident those are unrelated to what I actually changed inpackage.json. I've seen other keys flicker like this where I'm less confident that they're unrelated (devandoptionalDependencies).My completely unsubstantiated hunch is that this is somehow being caused by toggling between running
pnpm installfor the entire repository and for subsets of the repo by using--filter.pnpm version: 5.8.0
Code to reproduce the issue:
I don't have a concise repro for this yet. If it's helpful I can try and put something together, but it'll probably be a little contrived.
Expected behavior:
In a perfect world the lockfile would be stable, and changes would be (relatively) easy to explain by looking at the corresponding changes to
package.jsonfiles. We actually use subsets of the lockfile as cache key inputs for out build tool, so flickering like this triggers unnecessary recompilation. Aside from that, though I'm worried about confusion during code reviews (years of yarn has taught us to review changes to the lockfile since they can have wide impact).Actual behavior:
The lockfile "flickers" as described above.
Additional information:
node -vprints: v10.16.3