Create a package-lock.json file from pnpm-lock.yaml

[maclanzallamas]

It's clear how to do this the other way around with pnpm import (https://pnpm.io/cli/import)
But if I wanted to migrate from pnpm to npm, how do I use the pnpm-lock.yaml to create a package-lock.json file?

Similar question: #3356

Thanks

[frank-dspeed]

I am searching for the same answer i guess the most easy way is to do simply the migration to npm workspaces then do a npm install and drop pnpm the only compatible file is the package.json you can shim your dev environment like the one from pnpm with npm overrides.

That gives you the needed flexebility i am still exploring the patterns so i have no full workflow for that but it is in progress.

[bendman]

The ability to generate the package-lock file would also be useful for wiring other tools that use a package-lock.json, such as dependabot.

[frank-dspeed]

@bendman final conclusion is pnpm philosophie is that npm should integrate that if they want that they do not depend on package-lock.json so they see no need for interfaces and tooling even if contributed from outside.

my final conclusion is pnpm is gone wild and i will not use it anymore while i liked some design patterns they did use i do not agree with everything so the best is to simply go away from the monolit pnpm to something more modular managing dependencies with npm got much better with the last releases.

see: #4485

[zkochan]

If you need this feature, you need to ask for it in the npm CLI repository. Why would we spend our time on a feature that helps people switch away from pnpm to another package manager? It doesn't make sense.

[GorillaCoder]

Hi @zkochan, you say:
Why would we spend our time on a feature that helps people switch away from pnpm to another package manager? It doesn't make sense.

You wouldn't. You shouldn't. You need to get folks to adopt pnpm! 100% agree. Thing is, not supporting export to package-lock.json hurts pnpm. Slows its adoption. And, actually, doesn't do much to stop folks switching away from pnpm. It just pisses them off making it more likely they will leave.

Here's the thing. Our dev pipeline uses other tools. Projects like snyk. Projects that have limited resources and have deprioritized supporting pnpm. Why would they prioritize it, the pnpm community is small. How do you convince them to support you. By growing your community. And, much as you may not like it, that means supporting export to package-lock.json. You worry that supplying this feature will diminish your user base. I, and others here, are telling you it will ease our migration to pnpm. Want to grow your user base: support export to package-lock.json.

When you have crossed the tipping point, and are big enough that all the tools vendors have to support you, that's when you stop supporting export. Until then, not supporting export hurts pnpm

[weyert]

You make the contributions to those projects yourself, if you are eager to use PNPM and those tools. Or alternatively switch to a different tool that does support PNPM already. Or sponsor @zkochan to do this development work

[jamesmortensen]

I would love to be able to use PNPM more to save disk space and not keep repeatedly downloading the same node_modules to N different projects. Unfortunately, it feels clunky to use it without the ability to have it work with the tools my colleagues use. PNPM is a way better package manager than the other two major options. Working alone, I'll use PNPM, but I can't use it for any serious collaborative work, which is really a shame. We just can't get groups of people to all agree, so we adapt. I adapt by using NPM instead of PNPM, because managing the disk space is easier than dealing with the package-lock.json issue.

Unfortunately, npm i --package-lock-only didn't quite work for me on one of our legacy projects where there were some funky things happening with peer dependencies.

I get it. It's difficult for open source maintainers to prioritize everything. So the bigger question is would y'all be willing to accept a pull request that implements what folks are looking for?

[weyert]

That's a question for @zkochan to answer. Personally, I don't have issues with it but still think PNPM support needs to be added to the tooling (when open-source).

[zkochan]

Why would they prioritize it, the pnpm community is small.

It is not small.

If they decide not to support pnpm, they hurt themselves more than they hurt this project.

Or sponsor @zkochan to do this development work

Sponsoring is nice but I still decide what are my priorities. I don't see value in this. If someone wants to work on it, fine. But I don't want to.

[jamesmortensen]

It looks like this already may be possible, unless I'm misunderstanding the exact use case:

Generate a package-lock.json file without installing dependencies in node_modules:
npm i --package-lock-only

I was only using pnpm for demo projects to save disk space because I needed a package-lock.json on the CI servers, but it looks like I can just generate it via npm while keeping the node_modules symlinked to a central store. I think this means I can now use pnpm for work projects too.

See https://stackoverflow.com/a/54910009/552792

[frank-dspeed]

Amazing job and finding i need to document that you saved a lot of time your the hero of the day at present !!!

[PythonCoderAS]

This should be the accepted answer.

[frank-dspeed]

@PythonCoderAS it is already the accepted answer it works like a charm pnpm is now free and even useable with npm together via workspaces

mkdir project
cd project
npm init
npm init -w ./workspaces/pnpm-stuff
cd workspaces/pnpm-stuff
pnpm init
pnpm install
npm i --package-lock-only
cd ../..
npm install ## Will install and link all other workspaces and your current project including pnpm-stuff

So you can manage pnpm stuff inside pnpm and keep working with regular packages on projects that are not pnpm easy interop.

[zkochan]

With this solution you will have completely different packages in package-lock.json and pnpm-lock.yaml.

[frank-dspeed]

@zkochan thats correct after that point the package-lock.json is again the authoring format and pnpm-lock needs to get recreated from the package.json and package-lock.json but as users most of the time will have NPM at the root of the project and only do need pnpm as addition when they build and install some deps that depend on that its fine.

Most people do Only install to build there are less situations where you will ship the node_modules folder in production.

[rsheasby]

Sorry to necro this discussion but I wanted to add another POV. This feature would be very useful for my team not because we want to switch away from pnpm or because we want to do some unsupported deploy wizardry. On the contrary, this would be very useful because we don't want to switch away from pnpm, but some of our other tools don't support pnpm.

Specifically the issue we're having is with dependency scanning tools like snyk, semgrep, etc. These tools need to read a npm/yarn lock file in order to scan dependencies, but do not support pnpm, thus forcing us to choose between pnpm or dependency scanning (or using a clunky workaround, which is what we're currently investigating)

[rsheasby]

Why not spend the time to contribute to these tooling and add PNPM support?

I am working on exactly this with one of my vendors to add pnpm compatability, but it's significant effort for both teams because we do not know pnpm internals very well, and we each have higher priority items.

that energy can be better spend else where in the project

Sure, but you must understand that this merely offloads the energy to every user of your product to find workarounds, and every other tool that exists which doesn't have a large enough development team to justify spending effort to support a (relatively) uncommon package manager. Ultimately it's absolutely the choice of this project's maintainers to reject this feature request, but make no mistake: this is at the cost of people who want to use the project, and likely hinders adoption.

Adding the ability to output a package-lock.json would be a single fix that enables compatibility with dozens/hundreds of other projects, and reduces the duplicated effort required to add support to each individual project. It's a compatability feature that IMO is useful for many people.

Like I said, if this is something the pnpm team is unwilling to consider then that's entirely fine, but I honestly believe it comes at the cost of pnpm adoption.

[weyert]

Yeah, well, I personally I think it hinders adaption of those services if they don't support PNPM. Typically, they do take the time to support Yarn.

Does Yarn allow you to generate package-lock.json files?

I can understand for open-source products, but if I pay thousands of dollars per month for things like Snyk or Gitlab. I would expect they should support the major package managers. Creating a package-lock.json feature in PNPM also wouldn't help the increase the support for PNPM in such tooling. Which tooling are you exactly using that doesn't have PNPM lock file reading support?

I would hope that Snyk at least supports the SPDX / CycloneDX format that quite useful for SBOM etc.

[weyert]

Also we are using semgrep via Gitlab too but I am not aware it does any specific yarn or npm checks? What's the current unsupported functionality for semgrep? You might be in luck if it is needed to be able for me to use pnpm at work.

[rsheasby]

Are you using FOSS semgrep or Semgrep Supply Chain? Supply Chain does not support pnpm (which would be the only instance where you need to read the package list)

[weyert]

Probably Gitlab uses FOSS semgrep. Gitlab uses this as their vulnerability scanning:
https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium

Working on adding PNPM support

[weyert]

license-finder just added support for PNPM:
pivotal/LicenseFinder#954

[weyert]

Just now I found https://github.com/oss-review-toolkit/ort appears to support PNPM