Do we need lockfiles if all our dependencies are hosted on https://deno.land/x?
When I make a new Deno config, a lockfile is generated automatically and I don't understand why. I'm only using deno.land dependencies, which I think are immutable, and no NPM dependencies. Lockfiles are unwanted noise in my Git history. Is there any benefit to having it?
10 Replies
They aren't immutable unless you're using a specific version. Even when using a specific version, it's possible a dependency isn't using a specific version, so it won't be "locked".
That's when lockfiles are important, but not always, and not for every case, that's why you can set
"lock": false in deno.jsonAh, because Deno imports are resolved at import time recursively, an unversioned subdependency import could pull the latest. Hm, I think that makes sense but I kind of wish that version was injected at upload time so an import map was a) recursively immutable and b) cacheable. I feel like that's what the lockfile is doing.
Indeed!
If I understood it correctly, I think your suggestion introduces a race condition problem which lockfiles solve. In your suggestion, if a dependency is updated at the very moment you're building and uploading your app, then the version that would be injected and frozen inside your app online would be different from the version you worked on locally when developing
I am thinking of my app as specifying dependency versions but their subdependencies might not. My direct dependencies can't drift if their versions are specified but I don't have good control over subdependencies.
all of the static imports are resolved recursively, and you should receive a warning if one of them are unversioned, including subdependencies. So generally, if you're not getting a warning they should be the same all the way down.
While for practical purposes you can assume static-ness for versions on deno.land, I do think it's possible to change the code even if the version number doesn't change. It would require deleting and re-releasing a tag, I doubt anyone could do it on accident, but it's not cryptographically guaranteed the way something like nixpkgs dependencies are.
If someone re-released the tag, wouldn't my build break because I couldn't get the locked version?
You would be able to get the locked version. Say your app uses v1.2.0. If that version is rereleased, then there would be different code behind the same version number
But TBH, I usually don't use a lockfile
deno.land/x/ registry is immutable: re-releasing the same tag won't change code in the registry, deleting a tag won't delete it from the registry. The only reason for deletions is malicious code.
I'm glad to hear that!