Np: Supporting pnpm

[zkochan]

I'd like to use this lib with pnpm. It already supports Yarn, so I guess there would be no objections to supporting pnpm as well.

I created a lib that can detect the preferred-pm. First, it looks for a lockfile, if there is none, it can guess the PM by looking into the node_modules. So it can suggest a PM even when no lockfile is available.

For the commands, pnpm has the same CLI as npm.

[SamVerschueren]

To be honest, I already regret the fact that we added support for yarn. It has issues on every new
release of yarn... This package was written to support the needs of Sindre, me and some others. It was picked up by the community, which is awesome off course, but it's really a burden to have to support a feature that is not used by any of the maintainers.

[zkochan]

Well, I would like to use it as well with pnpm. So would you accept a PR if I make it better? I can try to create some package manager abstraction, to improve the current code quality and add pnpm

[sindresorhus]

I think it would be better to just fork np and make it pnpm specific. No matter how much you abstract, I'm the one that's going to have to deal with support, bugs, merging PR, and maintaining the code. The np code is already messy enough. I don't want to maintain more. Sorry.

[aleclarson]

Can we make a compromise and support pnpm lockfiles for the install step? Everything else can stay the same. :)

[itaisteinherz]

Can we make a compromise and support pnpm lockfiles for the install step? Everything else can stay the same. :)

@aleclarson I think that it doesn't really make sense to partially support something, and so I wouldn't vote for doing this. Feel free to use npm hooks to customise your installation scripts, but I don't think we'll integrate any new package managers into np in the near future.

[aleclarson]

@itaisteinherz In this context, partial support does make sense. Apart from the install step, pnpm integration wouldn't change the behavior in any meaningful way. But taking advantage of pnpm lockfiles speeds up the process and is very easy to support/maintain. I guarantee it. 😄

[itaisteinherz]

@aleclarson While that sounds reasonable and I would love to add such functionality to np, the cost of maintaining such a feature will be relatively high, and I wouldn't want to take that burden on myself (as well as on Sindre and Sam, of course).

As Sindre and Sam have already mentioned before, even the smallest things such as supporting Yarn for installing dependencies can cause quite a headache when there's a bug in Yarn, or when the API suddenly changed and nobody noticed it yet.

Nevertheless, I'd love to see how you would go about implementing this, so feel free to fork np and add support for pnpm (I propose npnpm as the package name (in case you'll publish the fork) 😉).

P.S. Note that opinions fluctuate, as do the circumstances, and so this discussion might have a different outcome in the future.

[itaisteinherz]

Also note that this is related to #386.

[tstewart-klaudhaus]

How about enabling users to skip the npm install step? I can't see any other issue with what np already does that would stop it working with an pnpm based workflow. I'm happy for the tests, publish etc. to be run via the npm command, which is what pnpm uses under the hood anyway, it's just npm's local storage patterns that I want to avoid by using pnpm install instead, and I can do that manually.

[joeldenning]

I also would like an option for skipping npm install (or supporting pnpm). Running npm install on a project with a pnpm-lock.yaml file can result in the wrong versions of libraries being used when running the prepublishOnly script. For now, I'm no longer using np because of that fear.