I just started to use pnpm as an alternative to npm and it's great!
However, I quickly ran into a problem: pnpm creates a pnpm-lock.yaml
file and it doesn't update my old package-lock.json
.
So here is what I could do:
- Get rid of my
package-lock.json
(so that I don't need to keep it up to date anymore) and keep thepnpm-lock.yaml
but I "force" people to use pnpm - Remove both lock files and pretend that "it's a library so it should always be up to date" (from a comment below this question on StackOverflow)
- Keep both files but I need to manually update the
package-lock.json
with npm because pnpm doesn't support it
For now, I disabled the creation of the pnpm lock file so that pnpm just acts for me as something which speeds up my installation process and I kept my package-lock.json
file.
I think this question is also applicable to someone who uses yarn, so I searched for it and found in this answer that there is a yarn import
command which creates a yarn lock file from a npm lock file. There is exactly the same command with pnpm (but it creates a pnpm lock file, obviously).
The problem is that it would force me to use something that I don't want to use anymore (npm) to be able to please others.
What do you think about that? Maybe you have another solution?
Edit:
Here's the answer of pnpm's creator:
You should always commit a lockfile. If you use @pnpmjs, you should commit pnpm-lock.yaml.
β Zoltan Kochan πΊπ¦ππΊ (@ZoltanKochan) October 29, 2020
You should not commit lockfiles of other package managers. So if you commit pnpm-lock.yaml, remote package-lock.json or yarn.lock.
Top comments (1)
By the way, I found that it's possible to force people to use pnpm too: pnpm.js.org/en/only-allow-pnpm