foster/denoland-deno
1
0
Fork 0
mirror of https://github.com/denoland/deno.git synced 2024-12-23 07:44:48 -05:00
Code Issues Packages 1 Wiki Activity
denoland-deno/tests/specs/lockfile/only_package_json/deno.lock.out

17 lines
262 B
Text
Raw Normal View History

fix(cli): Support deno.lock with only package.json present + fix DENO_FUTURE install interactions with lockfile (#23918) Fixes #23571. Previously, we required a `deno.json` to be present (or the `--lock` flag) in order for us to resolve a `deno.lock` file. This meant that if you were using deno in an npm-first project deno wouldn't use a lockfile. Additionally, while I was fixing that, I discovered there were a couple bugs keeping the future `install` command from using a lockfile. With this PR, `install` will actually resolve the lockfile (or create one if not present), and update it if it's not up-to-date. This also speeds up `deno install`, as we can use the lockfile to skip work during npm resolution.
2024-05-23 15:31:05 -04:00
{
feat: lockfile v4 by default (#25165) This won't be fully stabilized until 2.0 is released.
2024-08-26 19:01:50 -04:00
"version": "4",
"specifiers": {
feat: improve lockfile v4 to store normalized version constraints and be more terse (#25247) Stores normalized version constraints in the lockfile, which will improve reproducibility and will fix a bug with duplicate specifiers ending up in the lockfile. Also, gets rid of some duplicate data in the specifiers area of the lockfile.
2024-08-28 14:17:47 -04:00
"npm:@denotest/esm-basic@*": "1.0.0"
feat: lockfile v4 by default (#25165) This won't be fully stabilized until 2.0 is released.
2024-08-26 19:01:50 -04:00
},
"npm": {
"@denotest/esm-basic@1.0.0": [WILDCARD]
fix(cli): Support deno.lock with only package.json present + fix DENO_FUTURE install interactions with lockfile (#23918) Fixes #23571. Previously, we required a `deno.json` to be present (or the `--lock` flag) in order for us to resolve a `deno.lock` file. This meant that if you were using deno in an npm-first project deno wouldn't use a lockfile. Additionally, while I was fixing that, I discovered there were a couple bugs keeping the future `install` command from using a lockfile. With this PR, `install` will actually resolve the lockfile (or create one if not present), and update it if it's not up-to-date. This also speeds up `deno install`, as we can use the lockfile to skip work during npm resolution.
2024-05-23 15:31:05 -04:00
},
"workspace": {
"packageJson": {
"dependencies": [
feat: improve lockfile v4 to store normalized version constraints and be more terse (#25247) Stores normalized version constraints in the lockfile, which will improve reproducibility and will fix a bug with duplicate specifiers ending up in the lockfile. Also, gets rid of some duplicate data in the specifiers area of the lockfile.
2024-08-28 14:17:47 -04:00
"npm:@denotest/esm-basic@*"
fix(cli): Support deno.lock with only package.json present + fix DENO_FUTURE install interactions with lockfile (#23918) Fixes #23571. Previously, we required a `deno.json` to be present (or the `--lock` flag) in order for us to resolve a `deno.lock` file. This meant that if you were using deno in an npm-first project deno wouldn't use a lockfile. Additionally, while I was fixing that, I discovered there were a couple bugs keeping the future `install` command from using a lockfile. With this PR, `install` will actually resolve the lockfile (or create one if not present), and update it if it's not up-to-date. This also speeds up `deno install`, as we can use the lockfile to skip work during npm resolution.
2024-05-23 15:31:05 -04:00
]
}
}
}
Copy permalink