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
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
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.
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>
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.
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 #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 #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).
