Unexpected `deno.lock` update?
In this commit, how was
deno.lock updated to add a new transitive dependency to @deno/cache-dir, when its version wasn’t touched at all?9 Replies
cc @dsherret — given this is your project, maybe you know if you did something like bump the Deno version during this commit or something
I think you mean
@deno/graph and not @deno/cache-dir? @deno/cache-dir has a types only dependendy on @deno/graph. In an old version of deno, it would accidentally not add these types entries to the lockfile, so I believe what happened here is I upgraded Deno and it properly added that dependency to the lockfile now
https://github.com/denoland/deno_cache_dir/blob/0b2dbb2553019dd829d71665bed7f48f610b64f0/file_fetcher.ts#L6i meant that
graph was added to cache-dir’s dependencies within the deno.lock, yeahIt also might have been that type checking wasn't run before so that dependency wasn't pulled in
GitHub
fix(lockfile): track dependencies specified in TypeScript compiler ...
We should track dependencies in jsxImportSource, jsxImportSourceTypes, and types.
That way, for example, if someone removes or changes the jsxImportSource then we can remove those items from the lo...
No, not that one. I remember fixing something related, but can't find it atm
that type has been imported since dnt’s initial commit so i imagine you ran typechecking at least once in dax’s life before this :-)
grepped through all released changes in the last year for
lockfile and/or deno.lock and nothing seemed relevant, oh well. thanks anywaysI'm having trouble finding it as well. I think it may just be I never ran type checking on the file that used that 😅
hm, do you not do treewide type checking? :)