Try to find pnpm-lock.yaml file upwards on tree structure

[Yurickh]

What are you trying to accomplish?

Iterate the folder tree upwards in order to find a pnpm-lock file when the directory source points to a nested workspace.

This hopefully addresses #10758, but I'd like to be able to verify these changes against my own repository. Is there any way to point dependabot to a fork in GitHub? I couldn't find any docs on it.

Anything you want to highlight for special attention from reviewers?

I'm not familiar with ruby project standards, so please let me know if you'd rather structure tests or code in a different way. I tried following the existing standards, but might have missed something.

How will you know you've accomplished your goal?

• The test I've added was failing prior to the changes in code, which I hope is enough to reproduce the issue described in Dependabot doesn't work with monorepos using pnpm #10758.
• I'd like to test these changes against my own repository, but couldn't find a way to point dependabot to a fork.

Checklist

• I have run the complete test suite to ensure all tests and linters pass.
• I have thoroughly tested my code changes to ensure they work as expected, including adding additional tests for new functionality.
• I have written clear and descriptive commit messages.
• I have provided a detailed description of the changes in the pull request, including the problem it addresses, how it fixes the problem, and any relevant details about the implementation.
• I have ensured that the code is well-documented and easy to understand.

[sylver]

Having this specific issue with our repos and was surprised to discover this is not actually covered while pnpm is supported.

Would be great to have some maintainers attention, since this is mandatory for any monorepo out there and the PR is quite simple and straightforward

[abdulapopoola]

Thanks @Yurickh , @thavaahariharangit will be investigating in this area this week.

[thavaahariharangit]

How do you ensure this solution works? , Is there are any example repository to test this scenario? , I mean I could recreate the error, and check that changes that you have provided in the PR fixing the issue? please.

Based on the analysis on the ticket. If it is yarn monorepo, dependabot is failing. But I could not test that on the repo they have provided due to the dependencies using private registries. Could you please let me know your thoughts on this.

[Yurickh]

That's my question in the PR description exactly :)~
Is there a way to run dependabot against a fork? I'd gladly setup a reproduction repo if I knew how to, but I couldn't find any docs on it.

[Yurickh]

So far, I've ensured the fix works by adding a test that breaks on your main, and passes on my branch, but if that's not enough, please I'd be glad to help verify it in any manner you see fit.

[thavaahariharangit]

Give me sometime, I will recreate this problem on sample or general repo, and verify both pls

1. Does that gives the same error customer is facing
2. Fix that you given here, fixing that issue.

[thavaahariharangit]

Existing Yarn fixes added to the PNPM as well.

[thavaahariharangit]

@Yurickh

I did some more reading on this issue. As per the documentation.
pnpm-lock.yaml should be on the root folder. If that's the case then this changes need not to be there.

FYR: #6346 (comment)

[Yurickh]

Yes, you're right there's only a single pnpm-lock.yaml file, but it is not necessarily at the same directory as the updates.directory configuration in dependabot.
In our case, we specifically want a single PR per workspace package, so we separate the configuration in different updates groups, but then the lockfile is not updated correctly.
This change ensures that we can find the root even when updates.directory is not the root by itself.

[thavaahariharangit]

Yes, you're right there's only a single pnpm-lock.yaml file, but it is not necessarily at the same directory as the updates.directory configuration in dependabot. In our case, we specifically want a single PR per workspace package, so we separate the configuration in different updates groups, but then the lockfile is not updated correctly. This change ensures that we can find the root even when updates.directory is not the root by itself.

Thank you for this update, now I understood the problem, Trying to recreate this problem based on your comment. Give me sometime pls :)

[MattIPv4]

If it helps for reproducing, I just ran into this bug/failure mode in the wild: alveusgg/alveusgg#856

[thavaahariharangit]

@Yurickh and @MattIPv4

I have created a sample repo to recreate this problem

Note:
In above repo I have used below sample dependencies,

1. root level: [email protected]
2. project level: [email protected]

Without any updates to the current dependabot (without this PR changes), I saw below behaviors

Scenario 1

When updates.directory is

directories:
      - /
      - /packages/*

then PR's generated

 +---------------------------------------------+
 |     Changes to Dependabot Pull Requests     |
 +---------+-----------------------------------+
 | created | express ( from 4.10.0 to 4.21.1 ) |
 | created | vue ( from 3.2.0 to 3.5.13 )      |
 +---------+-----------------------------------+

Scenario 2

When updates.directory is

directories:
      - /

then PR's generated

 +---------------------------------------------+
 |     Changes to Dependabot Pull Requests     |
 +---------+-----------------------------------+
 | created | express ( from 4.10.0 to 4.21.1 ) |
 +---------+-----------------------------------+

Scenario 3

When updates.directory is

directories:
      - /packages/*

then PR's generated

 +----------------------------------------+
 |  Changes to Dependabot Pull Requests   |
 +---------+------------------------------+
 | created | vue ( from 3.2.0 to 3.5.13 ) |
 +---------+------------------------------+

As far as I know things are working as per the dependabot documentation.

Could you please help me on recreating the issue that we are planning to address by this PR changes.

FYI
@abdulapopoola and @landongrindheim

[sylver]

@thavaahariharangit as stated previously, we have the exact same problem, thus why I ended up here.
So I can confirm this is a real issue.

To help illustrate, here's (a simplified snippet of) our dependabot.yml:

updates:
  - package-ecosystem: npm
    directory: "/apps/portal"
    schedule:
      interval: daily
    open-pull-requests-limit: 2
    allow:
      - dependency-name: "@angular*"
      - dependency-name: "typescript"
    ignore:
      - dependency-name: "@angular*"
        versions: [">=18.0.0"]
      - dependency-name: "@angular*"
        update-types:
          - "version-update:semver-major"
      - dependency-name: "typescript"
        update-types:
          - "version-update:semver-minor"
          - "version-update:semver-major"
    groups:
      angular:
        patterns:
          - "@angular*"
        update-types:
          - "minor"
          - "patch"

  - package-ecosystem: npm
    directory: "/"
    schedule:
      interval: daily
    open-pull-requests-limit: 4
    ignore:
      # Handled by dedicated groups above
      - dependency-name: "@angular*"

• the first update is needed for specific versions to lock in the directory /apps/portal. Dependabot will update /apps/portal/package.json but not /pnpm-lock.yaml <= That's the problem
• the second will properly update any /**/package.json along with /pnpm-lock.yaml, as expected, since we don't filter in a sub-directory/package of the monorepo

Hope that helps.

[sylver]

@thavaahariharangit I just had a look at your sample repo. You have a pnpm-lock.yaml in the subdirectory packages/web, but that's not how it's supposed to work. In a monorepo, everything is handled by one pnpm-lock.yaml file at the root level, not within each workspace packages.

[Yurickh]

Here's a reproduction repro:
https://github.com/Yurickh/dependabot-core-repro

I've created a very simple pnpm workspaces repository with two packages with old dependencies, and as you can see in the PRs opened:

• https://github.com/Yurickh/dependabot-core-repro/pull/3/files
• https://github.com/Yurickh/dependabot-core-repro/pull/2/files
• https://github.com/Yurickh/dependabot-core-repro/pull/1/files

None of them updates the lock file, as you'd expect.