Filtering "since" behavior and lockfile behavior

[alexandresoro]

Hello,

I am migrating an existing project from npm to pnpm and love it so far!

By digging into the docs, I discovered a feature that I found really interesting but I wanted to understand some impacts.

From what I understand in the docs, it is possible to filter packages so that only the ones that contain changed files since a given commit/branch are kept: https://pnpm.io/filtering#--filter-since

I currently have a repo that looks like this:

/
-> packages
    -> a/
    -> b/

I have set up a pnpm-workspace.yaml file like:

packages:
  - "packages/*"

and the pnpm-lock.yaml lockfile is at root level.

What I try to achieve is to run - for example - test script only for packages that contain files that have changed compared to the main branch. The goal is to avoid running "useless" tests on PRs and save some precious build time.
So this is exactly what seems to cover the filter.

However, some of the PRs will only impact the lockfile that is located at root package.
In such case, I'd still like to run the test scripts on all packages.
The rationale is that some indirect dependency could have been updated via the lockfile, and I want to make sure that I run the full test suite to detect potential regressions.
Off the top of my head, this is the only use case where I expect the full test suite to be run while the packages won't change themselves.

In that case, does it mean that currently, the script won't run on any package since the only changes are outside of the packages? Or is there any specific logic for that case?
Is this filter meant to be used for this kind of use cases or am I twisting its use?

[tiagobento]

Did you ever find out the answer to your questions? I'd love to know how pnpm --filter deals with changes that only impact pnpm-lock.yaml. I'm trying to avoid full builds as much as possible, but every time a change is made to pnpm-lock.yaml I am compelled to run a full build, since any package could be impacted from the changes done to it.

[alexandresoro]

No unfortunately not.
I haven't checked recently, but I remember having a look at the source code when I opened this discussion. I could not find anything that led me to believe that there was a specific behavior with pnpm-lock.yaml.

So for now I'm still relying of full build.

[tiagobento]

Hey! Thx for the reply. Really appreciate it.

That's too bad, as a development experience with 0 full builds might not be possible if pnpm really doesn't currently look at the pnpm-lock.yaml file to determine what packages may be impacted by changes done to it.

@alexandresoro If I may ask... did you consider switching to individual lock files for each package? I thought about it and found it was much less reliable in terms of unifying dependency versions. I use syncpack but it only considers package.json files, so inconsistencies between packages could still occur...

[tiagobento]

@zkochan Any feedback?

[tiagobento]

Here's a good example of PR that ends up triggering a full builds when a partial build would suffice. https://github.com/apache/incubator-kie-tools/pull/2295/files