Age | Commit message (Collapse) | Author |
|
Ports for both BSDs contain patches to the same effect.
See
https://github.com/freebsd/freebsd-ports/blob/main/www/deno/files/patch-ext_node_ops_fs.rs
and
https://github.com/openbsd/ports/blob/8644910cae24458306b6a7c4ef4ef7811bc3d1f5/lang/deno/patches/patch-ext_node_ops_fs_rs
|
|
|
|
(#26323)" (#26613)
…s` (#26323)"
This reverts commit afb33b3c2597c9ec943f71218b236486fbc86e23.
Reverting because it caused a regression -
https://github.com/denoland/deno/issues/26612.
Closes https://github.com/denoland/deno/issues/26612.
|
|
Add info/hint for terminal errors related to Node.js globals:
- __filename
- __dirname
- Buffer
- global
- setImmediate
- clearImmediate
Closes https://github.com/denoland/deno/issues/17494
|
|
Extracted out of https://github.com/denoland/deno/pull/26558
Closes https://github.com/denoland/deno/issues/26578
|
|
Fixes: https://github.com/denoland/deno/issues/24713
Fixes: https://github.com/denoland/deno/issues/25855
|
|
Closes https://github.com/denoland/deno/issues/26583
|
|
Spend some time stepping through the npm client code and noticed that
the bearer token was different from ours. They do some double encoding
and @dsherret helped me in matching the encoding behavior.
Fixes https://github.com/denoland/deno/issues/26033
|
|
Closes https://github.com/denoland/deno/issues/26189
Closes https://github.com/denoland/deno/issues/26575
|
|
|
|
Removes an unwrap that falsely assumed the specifier is a valid
file path.
Fixes https://github.com/denoland/deno/issues/26209
|
|
Signed-off-by: Meir Blachman <meirblachman@gmail.com>
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
|
|
visible screen (#25997)
The --watch option should clear the screen scrollback buffer as well as
the screen itself.
On Ubuntu (22.04 Jammy) the 'clear' command generates
"\x1B[H\x1B[2J\x1B[3J"; that is:
- \E[H - cursor home
- \E[2J - clear entire screen
- \E[3J - clear entire screen & scrollback buffer.
By contrast, Deno defined CLEAR_SCREEN as "\x1B[2J\x1B[1;1H", which
fails to clear the scrollback buffer.
The "\E[H\E[2J\E[3J" sequence works on MacOS (Sonoma) (using printf);
I'm not able to test on Windows.
Closes https://github.com/denoland/deno/issues/26514
|
|
ext\node\polyfills\internal\crypto\_randomInt.ts (#26534)
Towards #24236
|
|
|
|
|
|
Fixes https://github.com/denoland/deno/issues/26509.
Ended up being a `deno_graph` bug causing the error to surface. This PR
updates `deno_graph` to pick up the fix and reverts the temporary
workaround that skipped JSON exports.
|
|
to replace executable (#26542)
|
|
(#26548)
|
|
newlines (#26547)
This is specifically for `deno install`/`deno add` commands.
* https://github.com/dprint/jsonc-parser/pull/49
Closes https://github.com/denoland/deno/issues/26543
|
|
|
|
Forwarding v2.0.3 commit to `main`
Co-authored-by: denobot <33910674+denobot@users.noreply.github.com>
Co-authored-by: bartlomieju <bartlomieju@users.noreply.github.com>
|
|
Hot-fix to unblock `v2.0.3` release
|
|
Temporary fix for #26509, so people don't get errors.
|
|
Accidentally added in https://github.com/denoland/deno/pull/26473/files
|
|
While testing, I found out that light-my-request relies on
`ServerResponse.connection`, which is deprecated, so I added that and
`socket`, the non deprecated property.
It also relies on an undocumented `_header` property, apparently for
[raw header
processing](https://github.com/fastify/light-my-request/blob/v6.1.0/lib/response.js#L180-L186).
I added it as an empty string, feel free to provide other approaches.
Fixes #19901
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
|
|
These benchmarks run on GitHub Actions and are extremely noisy, thus
not providing much value.
|
|
Closes https://github.com/denoland/deno/issues/26510
|
|
This changes denort to pass a static reference of the moude source bytes found in the binary to v8 instead of copying it.
|
|
To avoid situations like described in
https://github.com/denoland/deno/issues/26402
using `deno fmt` with `--ext` flag now requires to explicitly specify
list of files (or globs) to format.
Closes https://github.com/denoland/deno/issues/26402
|
|
We weren't passing the resolved npmrc settings to the install commands.
This lead us to always fall back to the default registry url instead of
using the one from npmrc.
Fixes https://github.com/denoland/deno/issues/26139
Fixes https://github.com/denoland/deno/issues/26033
Fixes https://github.com/denoland/deno/issues/25924
Fixes https://github.com/denoland/deno/issues/25822
Fixes https://github.com/denoland/deno/issues/26152
---------
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
|
|
|
|
(#26513)
|
|
|
|
We missed adding support for an array of formats being passed to
`util.styleText`.
Fixes https://github.com/denoland/deno/issues/26496
|
|
exposes node-api symbols in denort so that `deno compile` can run native
addons.
|
|
Fixes the issue described in
https://github.com/denoland/deno/issues/23882#issuecomment-2423316362.
The parent was starting to send a message right before the process would
exit, and the channel closed in the middle of the write. Unlike with
reads, we weren't cancelling the pending writes, which resulted in a
`Broken pipe` error surfacing to the user.
|
|
(#26495)
Fixes playwright on linux, as reported in
https://github.com/denoland/deno/issues/16899#issuecomment-2378268454.
The issue was that we were opening the socket in nonblocking mode, which
meant that subprocesses trying to use it would get a `EWOULDBLOCK` error
(unexpectedly). The fix here is to only set nonblocking mode on our end
(which we need to use asynchronously)
|
|
Fixes https://github.com/denoland/deno/issues/25194
|
|
Fixes #26498.
This was a sort of intentional decision originally, as I wanted to avoid
caching extra files that may not be needed. It seems like that behavior
is unintuitive, so I propose we cache all of the exports of listed jsr
packages when you run a bare `deno install`.
|
|
Fixes https://github.com/denoland/deno/issues/26180.
|
|
Towards https://github.com/denoland/deno/issues/26127
|
|
Fixes https://github.com/denoland/deno/issues/26104
Fixes https://github.com/denoland/deno/issues/26071
Fixes https://github.com/denoland/deno/issues/17757
|
|
In libuv on windows, `ERROR_INVALID_NAME` is mapped to `ENOENT`, but it
is mapped to `EINVAL` in our compat implementation, which causes the
issue #24899.
ref:
https://github.com/libuv/libuv/blob/d4ab6fbba4669935a6bc23645372dfe4ac29ab39/src/win/error.c#L138
closes #24899
closes #26411
closes #23635
closes #21165
closes #19067
|
|
Fixes https://github.com/denoland/deno/issues/26391
|
|
Adds another kind to `FixSuggestionKind` specifically for links
documentation pages.
|
|
Fixes #26179.
The original error reported in that issue is fixed on canary, but in
local testing on my windows machine, `next build` would just hang
forever.
After some digging, what happens is that at some point in next build,
readFile promises (from `fs/promises` ) just never resolve, and so next
hangs.
It turns out the issue is saturating tokio's blocking task thread pool.
We previously limited the number of blocking threads to 32, and at some
point those threads are all in use and there's no thread available for
the file reads.
What's taking up all of those threads? The answer turns out to be
`tokio::process`. On windows, child process stdio uses the blocking
threadpool: https://github.com/tokio-rs/tokio/pull/4824. When you poll
the child's stdio on windows, it spawns a blocking task per poll, and
calls `std::io::Read::read` in the blocking context. That call can block
until data is available.
Putting it all together, what happens is that Next.js spawns `2 * the
number of CPU cores` deno child subprocesses to do work. We implement
`child_process` with `tokio::process`. When the child processes' stdio
get polled, blocking tasks get spawned, and those blocking tasks might
block until data is available. So if you have 16 cores (as I do), there
are going to be potentially >32 blocking task threadpool threads taken
just by the child processes. That leaves no room for other tasks to make
progress
---
To fix this, for now, increase the size of the blocking threadpool on
windows. 4 * the number of CPU cores should be enough to leave room for
other tasks to make progress.
Longer term, this can be fixed more properly when we handroll our own
subprocess code (needed for detached processes and additional pipes on
windows).
|
|
Fixes https://github.com/denoland/deno/issues/26455
Signed-off-by: Ronny Chan <ronny.chan@okta.com>
|
|
|
|
Fixes #25926
Fixes #26004
|