Keeping an updated package-lock.json while working with pnpm-lock.yaml locally.

[tsathis]

Although there is a feature pnpm import, which imports from package-lock.json to pnpm-lock.yaml, I like to have the feature to do reverse of it too.

Why

Assume I'm working on a project that is not owned by me and which is using package-lock.json for a long time. But, I need to use pnpm in my machine and still keeping the remote projects dependencies updated. Obviously, I cannot force the others to use pnpm. Therefore, if I have a way to generate a package-lock.json from my local pnpm-lock.yaml before pushing it will be much useful.

Thank you.

[tsathis]

Does npm i --package-lock-only do what I need?

[zkochan]

Maybe but I would recommend to use the same package manager that others are using on that project. It will reduce issues both for you and for others. If a project uses npm, use npm. If you think pnpm would benefit the team, try to showcase them how pnpm is better and switch everyone to pnpm on that project.

[martin-braun]

This doesn't help. npm i --package-lock-only will create a package-lock.json that has different versions than pnpm-lock.yaml. As of now, using pnpm means to go all in. I agree with @zkochan, although this is not great of a satisfactory.

[rnarayana]

Another use-case for this is to run certain tools which depend on npm's lockfile: Examples are OWASP's dependency check for vulnerabilities, and trivy docker scan. npm i --package-lock-only works as long as i don't have local package dependencies (in a monorepo). Once local packages come in, I have to do npm link and stuff. its super messy.

[bgerm]

Veracode doesn't support pnpm either.

[stewones]

apparently bitrise too.

[weyert]

Gitlab and their license and dependency scanner tools now support pnpm. I was told mend.io / whitesource supports it now too. So you have some options now.

If your scanner accepts SBOM files you are good to go now. If you are allowed to use other open-source scanners

[weyert]

https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium/-/merge_requests/455

[mcapodici]

My use case is DigitalOcean App Platform seems to require it (it doesn't support pnpm yet), so have to go back to npm for now on this project (or set up a custom Dockerfile, which I am trying to avoid).

[martin-braun]

I support this and I think pnpm should stay compatible with npm by writing the package-lock.json regardless, and here is why:

1. As @rnarayana said: The tooling. Although one can argue that we better off having all those tools out there support pnpm instead, the other way around would require significantly less man-hours to the entire ecosystem.
2. pnpm doesn't really bring any significant benefit to containers that host one project only anyways, so I see no need to add more complexity in a CI pipeline than necessary. Don't get me wrong pnpm is great to work with in a local machine, but a single application container doesn't benefit from it, it's actually worse, since you need to install another dependency.

If pnpm cannot maintain npm compatibility, I would rather fight for npm getting the option to use a centralized store. Eventually, it would lead to the same outcome as it has happened with yarn, because yarn didn't want to support the package-lock.json either.