feat: Look for pnpm lockfiles in git-repo if not found in package repo

[ChilloManiac]

For pnpm monorepos its usually like so

.
├── .git
├── pnpm-lock.yaml
├── package.json
└── packages/
    ├── lib1/
    │   └── package.json
    └── lib2/
        └── package.json

In the current case this would default back to npm if inside lib1

[stevearc]

Instead of doing a separate vim.fs.find up to the git root (which is not guaranteed to exist), I'd prefer a solution that makes use of the fact that we're already doing get_candidate_package_files to find all possible package.json files. It would require a little refactoring, but we could inspect the directory of each of them for the lockfiles instead of just the one that we determine is the relevant package file.

[ChilloManiac]

Instead of doing a separate vim.fs.find up to the git root (which is not guaranteed to exist), I'd prefer a solution that makes use of the fact that we're already doing get_candidate_package_files to find all possible package.json files. It would require a little refactoring, but we could inspect the directory of each of them for the lockfiles instead of just the one that we determine is the relevant package file.

Yeah looking at that function, it would make more sense to have the logic there or a similar function.

Would it make sense to search for the closest lock-file, as well as the package.json?
The package.json is responsible for declaring the scripts, but the lock-file seems like the definitive package-manager declaration?

[ChilloManiac]

Maybe something like refactoring the pick_package_manager(package_file) function to find the closest lockfile from that package_file?

[stevearc]

What I am thinking is: we are already finding every possible package.json file in the hierarchy. We then take that list and find the closest one that has scripts defined. What if we also operated on that same list and searched for a lockfile in the same directory as that package.json file? Would require some refactoring because currently that list of package.json files is consumed immediately to find the right package file, so instead we would probably want to call it and then pass that list into two helpers, one to get the correct package file and one to find the lockfile.

[ChilloManiac]

Sounds good - I'll get on around to it

[ChilloManiac]

I've updated the PR

[ChilloManiac]

Not meaning to be disrespectful, but bumping this as it seems to have been forgotten @stevearc