deno/cli/cache
David Sherret 4f80d83774
feat(unstable): single checksum per JSR package in the lockfile (#22421)
This changes the lockfile to not store JSR specifiers in the "remote"
section. Instead a single JSR integrity is stored per package in the
lockfile, which is a hash of the version's `x.x.x_meta.json` file, which
contains hashes for every file in the package. The hashes in this file
are then compared against when loading.

Additionally, when using `{ "vendor": true }` in a deno.json, the files
can be modified without causing lockfile errors—the checksum is only
checked when copying into the vendor folder and not afterwards
(eventually we should add this behaviour for non-jsr specifiers as
well). As part of this change, the `vendor` folder creation is not
always automatic in the LSP and running an explicit cache command is
necessary. The code required to track checksums in the LSP would have
been too complex for this PR, so that all goes through deno_graph now.
The vendoring is still automatic when running from the CLI.
2024-02-15 14:49:35 -05:00
..
cache_db.rs chore: update copyright to 2024 (#21753) 2024-01-01 19:58:21 +00:00
caches.rs chore: update copyright to 2024 (#21753) 2024-01-01 19:58:21 +00:00
check.rs chore: update copyright to 2024 (#21753) 2024-01-01 19:58:21 +00:00
common.rs chore: update copyright to 2024 (#21753) 2024-01-01 19:58:21 +00:00
deno_dir.rs chore: update copyright to 2024 (#21753) 2024-01-01 19:58:21 +00:00
disk_cache.rs chore: update copyright to 2024 (#21753) 2024-01-01 19:58:21 +00:00
emit.rs chore: update copyright to 2024 (#21753) 2024-01-01 19:58:21 +00:00
incremental.rs chore: update copyright to 2024 (#21753) 2024-01-01 19:58:21 +00:00
mod.rs feat(unstable): single checksum per JSR package in the lockfile (#22421) 2024-02-15 14:49:35 -05:00
module_info.rs fix: upgrade to deno_ast 0.33 (#22341) 2024-02-09 01:40:26 +00:00
node.rs chore: update copyright to 2024 (#21753) 2024-01-01 19:58:21 +00:00
parsed_source.rs fix: upgrade to deno_ast 0.33 (#22341) 2024-02-09 01:40:26 +00:00