The changes introduced in #744 and #765 result in the use of the incorrect package manager in some cases, where yarn is used where npm should be used instead.

For context, I am working in a repository that has a package-lock.json rather than a yarn.lock file; and indeed, my team uses npm instead of yarn. However, when we added postman-code-generators as a dependency, we started getting errors in CI, because we use an internal npm registry, and yarn is not able to access it using the same configurations and authentication data as npm.

For some reason, neither our top-level package-lock.json, nor this package's own package-lock.json are triggering the first condition that detect-package-manager was supposed to check (the presence of a given package manager's lockfile), so it goes to step 2, which is to check what package managers are available in the machine. And indeed the CI runner we use has both npm and yarn available.

Unfortunately, in the presence of both npm and yarn, detect-package-manager gives precedence to yarn, for some reason. (This has been reported in egoist/detect-package-manager#11, but after a year, there's no resolution yet — or even acknowledgement of the issue by the developer, for that matter).

@aman-v-singh, do you think it would be possible to reorder the array returned by detect-package-manager's detect(), before it is used in npm/deepinstall.js, so that npm comes first in the list?