1
0
Fork 0
mirror of https://github.com/denoland/deno.git synced 2024-12-15 11:58:42 -05:00
Commit graph

9 commits

Author SHA1 Message Date
Bartek Iwańczuk
4e19474129
chore: remove DENO_FUTURE=1 from spec tests (#25329)
Towards https://github.com/denoland/deno/issues/25241
2024-08-31 21:25:32 +00:00
David Sherret
b708a13eb0
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
Bartek Iwańczuk
1f47248143
fix: adjust suggestion for lockfile regeneration (#25107)
Ref https://github.com/denoland/deno/pull/24436#issuecomment-2288568645
2024-08-20 20:13:17 +02:00
David Sherret
526f39fbb9
feat(FUTURE): terse lockfile (v4) (#25059) 2024-08-19 03:01:39 +00:00
Nathan Whitaker
795ed23b35
fix(future): Emit deno install warning less often, suggest deno install in error message (#24706)
Two small changes:

- In our BYONM errors, suggest running `deno install` instead of `npm
install` if `DENO_FUTURE` is set
- Only emit warning about `deno install` changes if you do `deno install
<foo>` with deno_future unset
2024-07-24 23:37:13 +00:00
Nathan Whitaker
a7531361ef
fix(cli): Explicitly cache NPM packages during deno install (#24190)
Fixes a regression introduced in
https://github.com/denoland/deno/pull/24170, where we wouldn't actually
set up the node modules dir on `deno install` if there was an up to date
deno lockfile present.

Previously we were relying on the fact that resolving pending module
resolution called `cache_packages` (which sets up the node modules dir).
When pending resolutions were removed, and the `resolve_pending`
function with it, we also removed the `cache_packages` call needed to
set up node modules.
2024-06-12 16:06:41 -07:00
David Sherret
448fe67b7a
feat(vendor): support modifying remote files in vendor folder without checksum errors (#23979)
Includes:

* https://github.com/denoland/deno_graph/pull/486
* https://github.com/denoland/deno_graph/pull/488
* https://github.com/denoland/deno_lockfile/pull/25
* https://github.com/denoland/deno_lockfile/pull/22
* https://github.com/denoland/deno_graph/pull/483
* https://github.com/denoland/deno_graph/pull/470
2024-05-28 14:58:43 -04:00
Nathan Whitaker
5de30c5323
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 12:31:05 -07:00
Bartek Iwańczuk
4e23a5b1fc
FUTURE: deno install changes (#23498)
This PR implements the changes we plan to make to `deno install` in deno
2.0.
- `deno install` without arguments caches dependencies from
`package.json` / `deno.json` and sets up the `node_modules` folder
- `deno install <pkg>` adds the package to the config file (either
`package.json` or `deno.json`), i.e. it aliases `deno add`
- `deno add` can also add deps to `package.json` (this is gated behind
`DENO_FUTURE` due to uncertainty around handling projects with both
`deno.json` and `package.json`)
- `deno install -g <bin>` installs a package as a globally available
binary (the same as `deno install <bin>` in 1.0)

---------

Co-authored-by: Nathan Whitaker <nathan@deno.com>
2024-05-08 12:34:46 -07:00