search

sindresorhus / np

A better `npm publish`
MIT License
7.56k stars 299 forks source link

Support pnpm in 2024? #729

Closed mmkal closed 9 months ago

mmkal commented 10 months ago

Hi there! I know this has been raised a quite a few times (https://github.com/sindresorhus/np/issues/694, https://github.com/sindresorhus/np/issues/638, https://github.com/sindresorhus/np/issues/628, https://github.com/sindresorhus/np/issues/251), but I figured worth asking again because:

  1. Since most of those issues, corepack became a thing and the packageManager field was introduced to package.json, with pnpm being an officially supported package manager by nodejs itself. corepack means that we wouldn't need to worry about versions of pnpm, or anything like that - if the user cares, they'd just specify it in packageManager as normal.
  2. I really don't think it'd be too hard! I use np with pnpm already, and all you have to do is set "np": {"cleanup": false} in package.json. But doing this is a shame, because the cleanup feature is helpful. And needing to remember to do it just adds friction.
  3. Looking at the code, there's a fair amount of messiness related to yarn and yarn berry. In my experience, pnpm is better behaved, and does more work for you, so I don't think it'd add to that messiness. I think a small refactor could make it cleaner/more maintainable overall - basically we'd just need to abstract the install node_modules and run a package.json script concepts.
  4. pnpm really is better, and it's being adopted more and more, so it's less of a niche request than it was in 2018.

So, my pitch is: if I could submit a PR that didn't add net complexity/maintenance burden, would it be accepted? I'd also be happy to help with maintaining it indefinitely - looking at pnpm-related bugs/pull requests etc.

sindresorhus commented 10 months ago

I'm willing to support pnpm if you can commit to maintain the pnpm-specific parts of the code 👍