foster/denoland-deno
1
0
Fork 0
mirror of https://github.com/denoland/deno.git synced 2024-12-14 19:37:59 -05:00
Code Issues Packages 1 Wiki Activity
denoland-deno/tests/specs/npm/lock_file_integrity_failure/main.out

13 lines
489 B
Text
Raw Normal View History

fix(npm): add support for npm packages in lock files (#15938) This commit adds support for npm packages in the lock file.
2022-10-25 12:20:07 -04:00
Download [WILDCARD]
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
error: Integrity check failed for package: "npm:@babel/parser@7.19.0". Unable to verify that the package
fix(lock): autodiscovery of lockfile (#16498) This commit adds autodiscovery of lockfile. This only happens if Deno discovers the configuration file (either "deno.json" or "deno.jsonc"). In such case Deno tries to load "deno.lock" file that sits next to the configuration file, or creates one for user if the lockfile doesn't exist yet. As a consequence, "--lock" and "--lock-write" flags had been updated. "--lock" no longer requires a value, if one is not provided, it defaults to "./deno.lock" resolved from the current working directory. "--lock-write" description was updated to say that it forces to overwrite a lockfile. Autodiscovery is currently not handled by the LSP.
2022-11-02 11:32:30 -04:00
is the same as when the lockfile was generated.
feat(lockfile): track JSR and npm dependencies in config file (#22004) See overview in https://github.com/denoland/deno_lockfile/pull/13
2024-01-22 16:31:12 -05:00
Actual: sha512-74bEXKX2h+8rrfQUfsBfuZZHzsEs6Eql4pqy/T4Nn6Y9wNPggQOqD6z6pn5Bl8ZfysKouFZT/UXEH94ummEeQw==
Expected: sha512-foobar!
fix(lock): autodiscovery of lockfile (#16498) This commit adds autodiscovery of lockfile. This only happens if Deno discovers the configuration file (either "deno.json" or "deno.jsonc"). In such case Deno tries to load "deno.lock" file that sits next to the configuration file, or creates one for user if the lockfile doesn't exist yet. As a consequence, "--lock" and "--lock-write" flags had been updated. "--lock" no longer requires a value, if one is not provided, it defaults to "./deno.lock" resolved from the current working directory. "--lock-write" description was updated to say that it forces to overwrite a lockfile. Autodiscovery is currently not handled by the LSP.
2022-11-02 11:32:30 -04:00
This could be caused by:
* the lock file may be corrupt
* the source itself may be corrupt
fix: adjust suggestion for lockfile regeneration (#25107) Ref https://github.com/denoland/deno/pull/24436#issuecomment-2288568645
2024-08-20 14:13:17 -04:00
Investigate the lockfile; delete it to regenerate the lockfile at "[WILDCARD]lock.json".
Copy permalink