Honestly, I can sort of see it making sense. The only time I need to look into my lockfile are to see the exact version of something I'm pulling in, and general

Honestly, I can sort of see it making sense. The only time I need to look into my lockfile are to see the exact version of something I'm pulling in, and generally I think I would be fine doing something like `lock-file-tool --show-me xxxx`. In Rust, there's a `cargo tree` command to see the tree of your exact resolved dependencies for when you want to see the whole thing expanded, so I generally don't use the lockfile for that anyhow. I certainly don't ever update my lockfile by hand, so there'd be no loss of usability in that regard. That said, I'm not super convinced that performance would necessitate this; if parsing the text file was really that slow, I think you could instead have a separate binary file created whenever the lockfile is changed that has a serialized representation of the lockfile along with a checksum to ensure that it's not out-of-sync, then hash the lockfile before using the binary representation. I guess it's possible that if the tooling is brittle or people try to edit their lockfile by hand, this might end up detecting an out-of-sync lockfile more often than not, but at that point I think the issue isn't really with the lockfile format.