`deno info` doesn't write lockfile

[lucacasonato]

$ mkdir demo
$ cd demo
$ echo "{}" > deno.json
$ deno info jsr:@std/bytes --config deno.json
...

$ cat deno.lock
cat: deno.lock: No such file or directory

Also missing a --lock-write flag

Version: Deno 1.40.3

[jtoppine]

Should it write to the lockfile?

I was under the assumption that deno info if purely informational tool. I use it all the time to inspect random modules before, or regardless of whether I'm actually going to use said module. Having deno cache those modules feels intuitive, but it would be surprising if it also wrote to the lockfile, which actually modifies the project (lockfile is part of the project in a way).

I have no strong opinion either way. But I think it would be good to mention such behaviour in the manual.

[lucacasonato]

@jtoppine I believe so. If you do not want it to modify the lockfile, use deno info --no-lock. I think it writing the lockfile is consistent with all other subcommands (deno run, deno cache, deno check, etc). In all of these commands there are cases where what you are running is relevant to the local project, and cases where it is not.

For example, as a one-off you may want to deno run some random script off the internet that deletes all files named .DS_Store from your project, without adding that script to the lockfile. Conversely, you may want to deno info npm:preact in your project to determine which version of preact your package resolves to.

I understand why you think that deno info should not modify deno.lock, however I think that understanding relies on an incorrect assumption about how deno info operates. Namely that it is purely a reporting tool. However, it is not - if you specify a specifier that you have never downloaded before, deno info will in fact download this specifier. There is an alternate world where deno info only shows you info about what's already on disk, and never downloads anything (so you'd have to run deno cache first), but that is not how deno info operates right now. Possibly this is something we could change for Deno 2.

For now, we'll go ahead with aligning the behaviour with other subcommands.