pnpm v7 support about yarnhook HOT 6 CLOSED

Works perfectly. Thanks!

from yarnhook.

Hi, thanks for reporting the issue!

I'm sorry to see you are having this issue. I've been meaning to do a major refactor for a long time, but I never got around to do it. I have a branch where I was experimenting and wrote some end-to-end tests to ensure correct behavior. (There are no tests in the main branch, unfortunately.)

If you have a quick fix in mind, it'd be more than welcome. My eventual goal is to do away with package manager detection and rely on the engines field of package.json. The documentation states that it's the right place to put your package manager (and version) in there.

Sorry for the brain dump, I really want to get back to maintaining and improving this package. But I want to fix your problem first without getting too much into what I ideally want. What do you think would be the least invasive way to support pnpm v7?

from yarnhook.

Thanks for the quick reply.

I think there are two quick ways around this. One is to use pnpm -v to detect pnpm version once a pnpm-lock.yml file is detected, but this will add overhead.

The second option is to allow passing the commandline flags to the package manager, configure the package manager to use, or both:

yarnhook --package-manager pnpm --package-manager-version 7.0.2 -- --some-pass-through-flag

Re the future, the engines field can be used to constrain usage to a version range, e.g., >=3.1.0, and therefore might not be very helpful in discerning the correct version.

Fortunately, newer versions of node add the packageManager field, which should be perfect for this use case since its purpose is basically to tell node itself exactly that - what package manager to use and in which version.

The only issue is that it's not very commonly use yet (or even known), so the docs would have to make clear that it is required.

from yarnhook.

Thanks for listing the viable options. I guess I'll go with offering more control to the user. As you mentioned, the other option would make it slightly slower, when it should be unnoticeably fast.

As for the package manager detection, I wasn't aware of packageManager field or Corepack. This is really interesting, but it seems to be experimental at this point, so basing the API around it might not be a good choice. Interestingly the design document contradicts the readme about the field to check. And it's not clear that <package manager name>@<version> notation allows for semver or not.

Honestly I'm not trying to debunk the packageManager field, I'm open to it and excited about Corepack development. But engines field seems more stable at this time and I would expect the users of yarnhook to be mindful of providing a sane version range that would not have backwards incompatibility issues.

from yarnhook.

When I checked the pnpm release notes again, I noticed that pnpm-lock.yaml and prefer-frozen-lockfile were introduced at the same time, so I wonder why we kept the old config flag at all. I guess there's no point in dwelling in that so I'll just change the config without any invasive refactoring.

from yarnhook.

Cut a new release, can you give it a try? The version is [email protected].

from yarnhook.