Fixes#28517.
The npm package info gets requested a bunch of times by deno_npm. Before
this PR, we were loading it from the FS and parsing it each and every
time. With a lot of dependencies (and large `registry.json` files), this
can lead to massive blowups in install times.
From the repro in #28517
before this PR:
```
Command being timed: "deno i"
User time (seconds): 538.54
System time (seconds): 56.49
Percent of CPU this job got: 198%
Elapsed (wall clock) time (h:mm:ss or m:ss): 4:59.45
Maximum resident set size (kbytes): 378976
```
this PR:
```
Command being timed: "deno-this-pr i"
User time (seconds): 1.29
System time (seconds): 1.56
Percent of CPU this job got: 68%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:04.16
Maximum resident set size (kbytes): 500864
```
So roughly an improvement from 339s to 4s. You can see that the max RSS
does increase a decent amount, which is the main downside. However, this
in memory cache is cleared once we're done caching npm packages, and IMO
the performance tradeoff is well worth it.
This also has a very noticable, though less drastic, effect on fresh
installs (no deno.lock) for smaller projects. Here's a clean nextJS
template project:
```
❯ hyperfine --warmup 5 --prepare "rm -rf node_modules deno.lock" "deno i" "deno-this-pr i"
Benchmark 1: deno
Time (mean ± σ): 765.0 ms ± 10.1 ms [User: 622.3 ms, System: 216.4 ms]
Range (min … max): 749.0 ms … 783.6 ms 10 runs
Benchmark 2: deno-this-pr
Time (mean ± σ): 357.2 ms ± 9.4 ms [User: 193.2 ms, System: 198.2 ms]
Range (min … max): 346.4 ms … 374.1 ms 10 runs
Summary
deno-this-pr ran
2.14 ± 0.06 times faster than deno
```
Ref https://github.com/denoland/deno/issues/26928.
This was originally a warning so potential bugs would be visible. Now
that the code has been working for a while without issues, and since the
warning can be triggered in a valid case (as in the issue above, where
the warnings also hid the real diagnostic), let's downgrade this from a
warning to a debug log.
This improves peer dependency resolution to be more relaxed and resolve
non-version matching ancestors similar to pnpm rather than introducing
duplicate dependencies. Deno will warn when this occurs. In the future,
we should look into introducing an option to have Deno error in this
scenario.
Fixes#20198
The Web Crypto implementation has been artificially limiting `ECDSA` to
only the “recommended” curve/hash pairs (`P‑256/SHA‑256` and
`P‑384/SHA‑384`). The underlying `ring` APIs enforced those pairs, so
any attempt to verify signatures produced with different digests (e.g.
`P‑384` with `SHA‑256`) failed with a “Not implemented” error.
This PR rewires the ECDSA sign/verify path to use RustCrypto’s `ecdsa`
crate instead of `ring`, computes digests separately, and uses the
prehash signing/verifying API so that any `sha1`, `sha256`, `sha384` or
`sha512` can be used with either curve. The JS `SubtleCrypto` bindings
were updated to drop the hard coded checks, and a new unit test
exercises `P‑384 + SHA‑256` to ensure non‑matching combos now round
trip.
---------
Signed-off-by: Gene Parmesan Thomas <201852096+gopoto@users.noreply.github.com>
Signed-off-by: gopoto <201852096+gopoto@users.noreply.github.com>
Co-authored-by: Divy Srivastava <dj.srivastava23@gmail.com>
Deno.serve `Request` abort signals are aborted by default even when it
is finished successfully. This PR gates this behavior behind the
"legacy_abort" which is the default right now.
Turning the `no_legacy_abort` runtime option on is a **breaking change**
and will only abort request signals when there is a failure, thereby
cannot be used to determine if the request finished. This aligns with
`fetch` API.
Ref https://github.com/denoland/deno/issues/27005
NOTE: Commit 27363d389 was incorrectly landed in main before the release
completed and is not included in v2.2.5. The official v2.2.5 release was made
from the v2.2 branch.
`import.meta.log` enables basic log filtering through
`env_logger`/`DENO_LOG`. Log levels are supported, and filenames can
also be used. for example: `DENO_LOG=ext:deno_http::00_serve.ts=warn`
This adds support for using a local copy of an npm package.
```js
// deno.json
{
"patch": [
"../path/to/local_npm_package"
],
// required until Deno 2.3, but it will still be considered unstable
"unstable": ["npm-patch"]
}
```
1. Requires using a node_modules folder.
2. When using `"nodeModulesDir": "auto"`, it recreates the folder in the
node_modules directory on each run which will slightly increase startup
time.
3. When using the default with a package.json (`"nodeModulesDir":
"manual"`), updating the package requires running `deno install`. This
is to get the package into the node_modules directory of the current
workspace. This is necessary instead of linking because packages can
have multiple "copy packages" due to peer dep resolution.
Caveat: Specifying a local copy of an npm package or making changes to
its dependencies will purge npm packages from the lockfile. This might
cause npm resolution to resolve differently and it may end up not using
the local copy of the npm package. It's very difficult to only
invalidate resolution midway through the graph and then only rebuild
that part of the resolution, so this is just a first pass that can be
improved in the future. In practice, this probably won't be an issue for
most people.
Another limitation is this also requires the npm package name to exist
in the registry at the moment.
This pr explicitly enables the `sysinfoapi` feature flag on `winapi` in
`deno_os`, so that `deno_os` and other deno crates that rely on it can
be built independently outside of the workspace on Windows.
