fix(licenses): list licenses specific to workspace member package

[BlueGreenMagick]

Closes #5689

Before this PR, pnpm licenses list could not be run for individual workspace packages. Even when it was run inside a workspace member package, the licenses of the entire workspace dependencies were listed.

After this PR, when pnpm licenses list is executed inside a workspace member package, only the licenses of that specific package dependencies will be listed.

For example, with a workspace dependency tree as following:

package1:
    dependencies:
        workspace:package2
        dep1
    devDependencies:
        dev1

package2:
    dependencies:
        dep2
    devDependencies:
        dev2

• cd package1; pnpm licenses list will output dep1, dep2, dev1 (dev)
• cd package2; pnpm licenses list will output dep2, dev2 (dev).

You can still run pnpm -w licenses list to get previous behavior. Also, filter rules arguments (e.g. --filter) take precedent.

[weyert]

I will have a look. I would think you would only need to filter by importerId?

[BlueGreenMagick]

I will have a look. I would think you would only need to filter by importerId?

It wouldn't work if the workspace package had another workspace package as dependency. When building dependency tree from lockfile, link: to workspace packages aren't followed.

It might also seem like you could get the list of importerId that the workspace package has as dependency recursively, and put that as includedImporterIds, but that doesn't work either. With this method, the devDependencies of workspace package dependency is listed as well, when it shouldn't be.

That's why I thought I had to modify lockfile-walker as well.

[weyert]

Ah interesting, yeah, think this would be one for @zkochan :)

What you are saying makes sense, though. Only not sure if the link: issue you describe is expected behaviour

[zkochan]

It might be possible to use existing filtering for this. We already have filtering that finds the workspace projects that are dependencies of a project, when the --filter=foo... option is used. Then those importer IDs could be passed to lockfile walker.

[BlueGreenMagick]

It might be possible to use existing filtering for this. We already have filtering that finds the workspace projects that are dependencies of a project, when the --filter=foo... option is used. Then those importer IDs could be passed to lockfile walker.

This creates an issue where devDependencies of dependency workspace projects are listed as well.

What you are saying makes sense, though. Only not sure if the link: issue you describe is expected behaviour

Should I modify lockfileWalkerGroupImporterSteps() to follow link: instead? This PR does feel quite hacky with how a single 'importer step' also returns dependencies of link: dependency, as that's not exactly one step.

[BlueGreenMagick]

The new commit changes lockfile walker so that it can be used to follow links. Because LockfileWalkerStep.links were not previously used anywhere, it doesn't change any observable behavior.

[zkochan]

The change looks a bit complicated. Let's work on it after a stable version of v9 is out.