1
0
Fork 0
mirror of https://github.com/denoland/deno.git synced 2024-12-26 17:19:06 -05:00
Commit graph

16 commits

Author SHA1 Message Date
David Sherret
b1f776adef
refactor: extract structs for downloading tarballs and npm registry packuments (#24067) 2024-06-03 01:39:13 +00:00
Nathan Whitaker
a379009bfd
fix(cli): Prefer npm bin entries provided by packages closer to the root (#24024)
Fixes #24012.

In the case of multiple packages providing a binary with a same name, we
were basically leaving the results undefined (since we set up things in
parallel, and whichever got set up first won). In addition, we were
warning about these cases, even though it's a situation that's expected
to occur.

Instead, in the case of a collision in the binary names, we prefer the
binary provided by the package with the least depth in the dependency
tree.

While I was at it, I also took moved more code to `bin_entries.rs` since
it was starting to get a bit cluttered.
2024-05-29 17:45:22 -07:00
Nathan Whitaker
2024c974b6
perf(cli): Improve concurrency when setting up node_modules and loading cached npm package info (#24018)
The same issue in two different places - doing blocking FS work in an
async task, limiting the amount of work that happens concurrently.

- When setting up node_modules, where we try to set up entries
concurrently but were blocking other tasks from actually running.
- When loading package info from the npm registry file cache, loading
and deserializing is expensive and prevents concurrency. This was
especially noticeable when loading an npm resolution snapshot from a
lockfile (`snapshot_from_lockfile` in `deno_npm`).

Installing deps in `deno-docs`:

```
❯ hyperfine -i -p 'rm -rf node_modules/' '../d7/deno-main i' '../d7/target/release/deno i'
Benchmark 1: ../d7/deno-main i
  Time (mean ± σ):      2.193 s ±  0.027 s    [User: 0.589 s, System: 1.033 s]
  Range (min … max):    2.151 s …  2.242 s    10 runs

Benchmark 2: ../d7/target/release/deno i
  Time (mean ± σ):      1.597 s ±  0.021 s    [User: 0.977 s, System: 1.337 s]
  Range (min … max):    1.550 s …  1.627 s    10 runs

Summary
  ../d7/target/release/deno i ran
    1.37 ± 0.02 times faster than ../d7/deno-main i
```

Caching `npm:@11ty/eleventy`:
```
❯ hyperfine -i -p 'rm -rf node_modules/' --warmup 5 '../../d7/deno-main cache npm:@11ty/eleventy' '../../d7/target/release/deno cache npm:@11ty/eleventy'
Benchmark 1: ../../d7/deno-main cache npm:@11ty/eleventy
  Time (mean ± σ):     129.9 ms ±   2.2 ms    [User: 27.5 ms, System: 101.3 ms]
  Range (min … max):   127.5 ms … 135.8 ms    10 runs

Benchmark 2: ../../d7/target/release/deno cache npm:@11ty/eleventy
  Time (mean ± σ):     100.6 ms ±   1.3 ms    [User: 38.8 ms, System: 233.8 ms]
  Range (min … max):    99.3 ms … 103.2 ms    10 runs

Summary
  ../../d7/target/release/deno cache npm:@11ty/eleventy ran
    1.29 ± 0.03 times faster than ../../d7/deno-main cache npm:@11ty/eleventy
```

---------

Co-authored-by: David Sherret <dsherret@gmail.com>
2024-05-28 21:17:36 +00:00
Nathan Whitaker
3e8f29ae41
perf(cli): Optimize setting up node_modules on macOS (#23980)
Hard linking (`linkat`) is ridiculously slow on mac. `copyfile` is
better, but what's even faster is `clonefile`. It doesn't have the space
savings that comes with hardlinking, but the performance difference is
worth it imo.

```
❯ hyperfine -i -p 'rm -rf node_modules/' '../../d7/target/release/deno cache npm:@11ty/eleventy' 'deno cache npm:@11ty/eleventy'
Benchmark 1: ../../d7/target/release/deno cache npm:@11ty/eleventy
  Time (mean ± σ):     115.4 ms ±   1.2 ms    [User: 27.2 ms, System: 87.3 ms]
  Range (min … max):   113.7 ms … 117.5 ms    10 runs

Benchmark 2: deno cache npm:@11ty/eleventy
  Time (mean ± σ):     619.3 ms ±   6.4 ms    [User: 34.3 ms, System: 575.6 ms]
  Range (min … max):   612.2 ms … 633.3 ms    10 runs

Summary
  ../../d7/target/release/deno cache npm:@11ty/eleventy ran
    5.37 ± 0.08 times faster than deno cache npm:@11ty/eleventy
```
2024-05-28 11:59:17 -07:00
Bartek Iwańczuk
92a8d09e49
fix(npm): set up node_modules/.bin/ entries for package that provide bin entrypoints (#23496)
Closes https://github.com/denoland/deno/issues/23036

---------

Co-authored-by: Nathan Whitaker <nathan@deno.com>
2024-05-23 23:43:38 +00:00
Bartek Iwańczuk
959739f609
FUTURE: initial support for .npmrc file (#23560)
This commit adds initial support for ".npmrc" files.

Currently we only discover ".npmrc" files next to "package.json" files
and discovering these files in user home dir is left for a follow up.

This pass supports "_authToken" and "_auth" configuration
for providing authentication.

LSP support has been left for a follow up PR.

Towards https://github.com/denoland/deno/issues/16105
2024-05-23 23:26:23 +02:00
David Sherret
9795637724
fix(task): do not error if node_modules folder not exists (#23920)
Revealed https://github.com/denoland/deno/issues/23919

Closes #23914
2024-05-21 16:12:14 -04:00
David Sherret
bc4aa5f901
fix(npm): do not panic hitting root dir while resolving npm package (#23556)
Closes https://github.com/denoland/deno/issues/23029
2024-04-25 14:13:55 +00:00
Divy Srivastava
e0c9102b49
perf: hard link npm cache (#22773) 2024-03-07 13:10:19 -05:00
David Sherret
7e72f3af61
chore: update copyright to 2024 (#21753) 2024-01-01 19:58:21 +00:00
David Sherret
9bdc9e4ecb
fix(npm): do not create symlink for non-system optional dep in node_modules directory (#21478)
Closes https://github.com/denoland/deno/issues/21476
2023-12-06 14:24:00 -05:00
David Sherret
9ac405d587
feat(compile): support "bring your own node_modules" in deno compile (#21377)
Not tested thoroughly. This is a good start.

Closes #21350
2023-11-29 09:32:23 -05:00
David Sherret
be97170a19
feat(unstable): ability to npm install then deno run main.ts (#20967)
This PR adds a new unstable "bring your own node_modules" (BYONM)
functionality currently behind a `--unstable-byonm` flag (`"unstable":
["byonm"]` in a deno.json).

This enables users to run a separate install command (ex. `npm install`,
`pnpm install`) then run `deno run main.ts` and Deno will respect the
layout of the node_modules directory as setup by the separate install
command. It also works with npm/yarn/pnpm workspaces.

For this PR, the behaviour is opted into by specifying
`--unstable-byonm`/`"unstable": ["byonm"]`, but in the future we may
make this the default behaviour as outlined in
https://github.com/denoland/deno/issues/18967#issuecomment-1761248941

This is an extremely rough initial implementation. Errors are
terrible in this and the LSP requires frequent restarts. Improvements
will be done in follow up PRs.
2023-10-25 14:39:00 -04:00
David Sherret
8c1677ecbc
refactor(npm): break up NpmModuleLoader and move more methods into the managed CliNpmResolver (#20777)
Part of https://github.com/denoland/deno/issues/18967
2023-10-03 19:05:06 -04:00
David Sherret
148694eb35
refactor(npm): make NpmCache, CliNpmRegistryApi, and NpmResolution internal to npm::managed (#20764) 2023-10-02 17:53:55 -04:00
David Sherret
8d24be1a59
refactor(npm): create cli::npm::managed module (#20740)
Creates the `cli::npm::managed` module and starts moving more
functionality into it.
2023-09-30 12:06:38 -04:00