As suggested in
https://github.com/denoland/deno/pull/24355#discussion_r1657875422.
I wasn't able to hide the mutex stuff as much as I'd like (ended up just
adding an escape hatch `inner()` method that locks the inner mutex),
because you can't return references to the inner fields through a mutex.
This is mostly motivated by the frozen lockfile changes
This commit adds discovery of `.npmrc` files in user's homedir.
This is not a perfect fix as it doesn't merge multiple `.npmrc` files
together as per https://github.com/denoland/deno/issues/23954
but allows to fallback if no `.npmrc` file is discovered in the project
root.
- add fallback impls of external string apis which always copy. after
upstream changes to rusty_v8 we can support non-copying api as well.
- `napi_get_buffer_data` needs to work on all TypedArray instances.
- Fixes: https://github.com/denoland/deno/issues/24209
- `target_defaults.default_configuration` is used by some modules to
find the corresponding node file from node-gyp
- `node_api_get_module_filename` expects the filename to be a `file:`
url.
This is the release commit being forwarded back to main for 1.44.3
Co-authored-by: bartlomieju <bartlomieju@users.noreply.github.com>
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
Fixes#23493.
What was happening here was that napi-rs was freeing the napi reference
([here](19e3488efc/crates/napi/src/bindgen_runtime/mod.rs (L62)))
during its finalize callback (which we call
[here](fb31eaa9ca/cli/napi/js_native_api.rs (L132))).
We then were [reading the `ownership`
field](fb31eaa9ca/cli/napi/js_native_api.rs (L136))
of that freed reference.
For some reason on arm macs the freed memory gets zeroed, so the value
of `ownership` was `0` when we read it (i.e. it was
`ReferenceOwnership::Runtime`). We then freed it again (since we thought
we owned it), causing the segfault.
This commit updates Deno to use `reqwest` at 0.12.4
and `rustls` at 0.22. Other related crates were updated
as well to match versions accepted by `reqwest` and `rustls`.
Note: we are not using the latest available `rustls` yet,
but this upgrade was non-trivial already, so a bump to
0.23 for `rustls` will be done in a separate commit.
Closes#23370
---------
Signed-off-by: Ryan Dahl <ry@tinyclouds.org>
Signed-off-by: Bartek Iwańczuk <biwanczuk@gmail.com>
Co-authored-by: Ryan Dahl <ry@tinyclouds.org>
Co-authored-by: Divy Srivastava <dj.srivastava23@gmail.com>
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.
Fixes#22050.
It seems very unlikely that a user would be intending to enable deno's
internal debug logs by setting the DEBUG env var. If they really want
that, they can set `RUST_LOG=debug` instead.
Previously various reads of files in `node_modules` would error on
invalid UTF-8. These were cases involving:
- reading package.json from Rust
- reading package.json from JS
- reading CommonJS files from JS
- reading CommonJS files from Rust (for ESM translation)
- reading ESM files from Rust
Also removes permissions being passed in for node resolution. It was
completely useless because we only checked it for reading package.json
files, but Deno reading package.json files for resolution is perfectly
fine.
My guess is this is also a perf improvement because Deno is doing less
work.
This is the release commit being forwarded back to main for 1.44.1
Co-authored-by: devsnek <devsnek@users.noreply.github.com>
Co-authored-by: Divy Srivastava <dj.srivastava23@gmail.com>
Introduces a `SyncReadAsyncWriteLock` to make it harder to write to the
npm resolution without first waiting async in a queue. For the npm
resolution, reading synchronously is fine, but when updating, someone
should wait async, clone the data, then write the data at the end back.
