turbo

0b094075 - fix(lockfiles) no longer error when parsing out of date pnpm lockfiles (#6048)

fix(lockfiles) no longer error when parsing out of date pnpm lockfiles (#6048) ### Description Fixes #6030 The reason behind the triggering of unrelated workspaces is that the pnpm lockfile implementation would error if it couldn't find a package that was listed in `package.json`. Users can easily get in this situation if they add a dependency in a commit. The fix is to not error and instead return `None` like all other lockfile implementations. This behaves how we want since when comparing the two parsed lockfiles in `context.ChangedPackages` we check that the old lockfile closure has the same packages. Note: I did some `git` spelunking and I couldn't find any reason why I initially implemented this to happen in back in Go. I'm chalking this up to lack of knowledge about the pnpm lockfile format. ### Testing Instructions Added unit test to make sure we no longer error when calculating the transitive closure based on a newer `package.json`. Also verify that the repro from the issue now doesn't trigger a change for docs: Setup script: ``` pnpm dlx create-turbo@canary test-lockfile-invalidation --package-manager pnpm cd test-lockfile-invalidation/apps/web pnpm add left-pad git add --all git commit -m "Add left-pad" ``` Verify that `docs` isn't an affected package from the `left-pad` addition: ``` [0 olszewski@chriss-mbp] /tmp/test-lockfile-invalidation $ turbo_dev --skip-infer build --filter='docs...[HEAD^1]' • Packages in scope: • Running build in 0 packages • Remote caching disabled No tasks were executed as part of this run. Tasks: 0 successful, 0 total Cached: 0 cached, 0 total Time: 436ms ``` Closes TURBO-1370 --------- Co-authored-by: Chris Olszewski <Chris Olszewski>