[BUG]: Package manager detection could be more precise

georgzoeller commented 1 month ago

dmno version

0.0.21

Steps to reproduce

If you have dangling lockfiles from another package manager, things get complicated

have pnmp-lock.yaml and bunb.lock files in your directory
run dmno init

What is expected?

Error that package managers can't be resolved because there is multiple lockfiles
Maybe query the package.json packageManager field first before going to lockfile detection.

What is actually happening?

It's running the first package manager identified based on lockfile. which in my case was no longer installed

System Info

No response

Any additional comments?

No response

philmillman commented 1 month ago

@theoephraim relevant to PR #121

theoephraim commented 1 month ago

I'm a bit wary of involving the packageManager field, since technically only pnpm and yarn are supported. Although I suppose I could check it as an additional signal and throw an error if we find it doesn't match the others?

One thing that does make things a bit more complicated is that in a monorepo, we could be walking up the folder tree and find multiple lockfiles at multiple levels. I don't think there's a perfect way to know which file is abandoned.

Another signal I can use is process.env.npm_config_user_agent which gets injected by the package managers when running scripts (ex: npm run dev) or for executing dependency binaries (ex: npm exec dmno init, npx dmno init). This of course will not be present if not running something via the package manager (ex: node main.js). Currently I only use this if we did not find any lockfiles.

For now, I'll add the additional check that we did not find 2 lockfiles at the same level before returning. (see https://github.com/dmno-dev/dmno/commit/1a4cd5d0ac3e87da167bc99df3997bfad1731e96)

dmno-dev / dmno