Reduce verbosity when a single version changes

[dsherret]

Based on feedback from Ry, it would be ideal if the lockfile only stored the version of a package once when there is only one version of a package (jsr or npm). For example, bumping the patch of an npm package should have one change and not many changes.

Probably the "dependencies" field's value should not have a version number if there's only one version of a package.

[zebreus]

The current state on #26 only omits the version number if the dependency contains an exact version and not a version requirement. This behaviour means that nearly no version numbers are omitted in many real-life scenarios, as most dependencies will come with a version requirement like @^1.3.2 and not an exact version like @1.3.2.

We can just completely omit the version number in dependencies when we only lock one version of a package. If we lock multiple versions, we should put the exact version number and not the range into the dependencies. I think that this is the cleanest solution and that it will significantly increase reviewability.

However this would introduce some problems for updating the specifiers map, as we no longer have enough information to figure out which specifier was introduced because of which dependency. This makes it impossible to remove dependencies from the lockfile without looking at the code. However, we currently already have the same situation for https dependencies and redirects and are fine with it. Updating the lockfile without looking at the code it is derived from should just be out of scope for the lockfile format.

[dsherret]

The current state on #26 only omits the version number if the dependency contains an exact version and not a version requirement.

I think it does this for the version requirements as well? For example: https://github.com/denoland/deno_lockfile/pull/26/files#diff-f17d73055cd722fdb26b6d1d26f24bbdede5698113058d9762f63d173d6b4c79R27

However this would introduce some problems for updating the specifiers map, as we no longer have enough information to figure out which specifier was introduced because of which dependency.

Yes, you're correct. We decided this is an ok tradeoff.