* fix: lockfile v6 should not be corrupted on repeat install
* fix: don't add empty specifiers to lockfile v6
* fix: lockfile v6 should be saved to node_modules/.pnpm/lock.yaml
* fix: frozen lockfile with lockfile v6
* refactor(dependencies-hierarchy): remove keypath argument from getTree
The `keypath` argument is an internal implementation detail of `getTree`
used to detect cycles in the package graph. Removing this from the call
signature of `getTree` since it exposes an implementation detail.
The start of a `getTree` call always passed in the starting node as the
initial value anyway.
```ts
const getChildrenTree = getTree.bind(null, { ... })
getChildrenTree([relativeId], relativeId)
```
It's simpler for that to happen in the first call to `getTreeHelper`
internally and better ensures the keypath is created correctly. A future
refactor makes construction of the keypath more involved.
* refactor(dependencies-hierarchy): remove refToRelative call in getPkgInfo
This removes an extra `refToRelative` call in `getPkgInfo`. The result
of this call wasn't used within the function and was simply passed back
to the caller.
Callers of `getPkgInfo` were checking the result of `refToRelative`,
from `getPkgInfo`'s return object only to call `refToRelative` again.
Calling `refToRelative` directly simplifies code a bit. We can remove an
unnecessary cast and an if statement.
* refactor(dependencies-hierarchy): create enum for getTree nodes
* feature(dependencies-hierarchy): traverse through workspace packages
This updates `pnpm list` and `pnpm why` to traverse through `link:`
packages by simply. This is done by simply implementing a new TreeNodeId
enum variant.
* test(dependencies-hierarchy): test transitive workspace package listing
* refactor(dependencies-hierarchy): create interface for GetPkgInfoOpts
A future commit adds new fields to `getPkgInfo`'s options. The dedicated
interface makes it easier to describe these new options with a JSDoc.
* fix(dependencies-hierarchy): fix path for link: deps in projects
This was a bug before the changes in this pull request. The bug was not
user facing since `pnpm list --json` doesn't print this computed path.
* fix(dependencies-hierarchy): print version paths rel to starting project
* feat(list): add --only-projects flag
* refactor: change description of --only-projects
Co-authored-by: Zoltan Kochan <z@kochan.io>
The numerical `height` value isn't used if `isPartiallyVisited` is set.
Merging these two fields makes that more clear.
The definition of the `height` field used in getTreeHelper is also
updated to include the parent node in this commit. This makes the field
consistent with the `height` definition in DependenciesCache.
The `resultHeight` and `resultIsPartiallyVisited` variables were only
being updated on cache misses by mistake.
This commit updates the `DependenciesCache` to provide these variables
based on previous `getTreeHelper` calls.
Looking over this again, it looks like this never tested the fully
visited cache. The `a` package was never added to the fully visited
cache since the dependencies of its leaf nodes were never enumerated.
Adding a comment to make this more clear and increasing the max depth
of the test case.
This previously double incremented `resultHeight`. When writing this,
I was thinking the child node's height was 1 more than the call for its
dependencies. The parent node (the result) would then be more more than
that.
However, `resultHeight`'s definition is based the longest edge in the
dependencies array returned, which doesn't include the parent node. The
additional `+ 1` to account for the parent node should never have been
added.
In a debugger, I noticed a test package with no dependencies return a
height of `0` from getTree. By the comment in `DependencyInfo`, this
should instead be `null` since the dependencies array is empty.
It turns out this is the case when `deps == null`. The `getTree`
function early returns with a `null` height:
```ts
if (deps == null) {
return { dependencies: [], isPartiallyVisited: false, height: null }
}
```
However, when `deps` is `{}`, `resultHeight` gets initialized to `0`.
The subsequent `.forEach` loop then iterates over the non-empty object.
* test(dependencies-hierarchy): start currentDepth at 1 in tests
Calls to `getTree` from the `buildDependenciesHierarchy` function always
start the `currentDepth` at `1` rather than `0`.
Updating `currentDepth` calls in test to also start at `1` for
consistency with production code. This required incrementing the
`maxDepth` argument in a few cases as well.
* refactor(dependencies-hierarchy): simplify max depth recursion
