summaryrefslogtreecommitdiff
path: root/tests/specs/install/future_install_node_modules
AgeCommit message (Collapse)Author
2024-07-24fix(future): Emit `deno install` warning less often, suggest `deno install` ↵Nathan Whitaker
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-06-12fix(cli): Explicitly cache NPM packages during `deno install` (#24190)Nathan Whitaker
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-05-28feat(vendor): support modifying remote files in vendor folder without ↵David Sherret
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-23fix(cli): Support deno.lock with only package.json present + fix DENO_FUTURE ↵Nathan Whitaker
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-08FUTURE: `deno install` changes (#23498)Bartek Iwańczuk
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>