I disagree. The current package lock may as well be binary. The performance differences of binary serialization are not to be underestimated. There will be a spec and you can write your own implementation.

The problem is that all existing tooling needs to adapt, from custom package repositories to security scanners. It’s no longer possible to use grep to find out which of your projects’ dependencies use a vulnerable package.

This is a step backwards IMO.

So you pipe through one more thing to get in text form, I don’t think it’s a big problem. I would much prefer a binary format for the perf

It is a problem because it creates a trust vector between the binary vendor and the app developer consuming the binary.

Sure, there is going to be a build-your-own kit, but is everyone going to audit the codebase and the tooling and all dependencies?

It’s a fresh new can of worms and we’re already overstocked.

There’s already a trust vector between the people shipping all the tiny little pieces of garbage JS, and then on to the binaries that read and handle dependency management, and packaging, and so on-things which, as has been expressed, seem to be in a rolling two-years-or-less handbasket to at least “mess”, if not “hell”.

We’re already to the point where “no one” audits the code base, tooling, or dependencies. Especially the dependencies.

I really don’t think deserializing the file is that sketchy. It’s really not hard to implement a parser if the format isn’t garbage