* node:http: emit 'socket' event after calling http.request()
* add reference links for why this is how it is
* add guards to not waste time
* add a regression test
* use test harness port number
* node:url implement domainToASCII and domainToUnicode
* fix arg checks
* remove unneeded use of WTF::Vector
* tidy
* throw a js error if icu fails
* add a ton more tests, fix ascii guard, upconvert latin1
* even more tests
* add a comment for this guard
* use ASSERT_NOT_REACHED() instead of raise(SIGABRT)
* Slightly reduce number of system calls on Linux
* Fix regression from 648d5aecf3648d5aecf3 caused HTTP response bodies sent streamingly with a single chunk to include an extraneous 0\r\n\r\n chunk, leading valid clients to close the connection prematurely.
---------
Co-authored-by: Jarred Sumner <709451+Jarred-Sumner@users.noreply.github.com>
* feat(options): add possibility to append a custom esm condition
* feat(cli): parse --conditions flag
* test: add case for custom conditions
* fix(cli): not get short-hand --conditions flag
* test: add case using cjs with custom condition
* fix(options): address possible memory issues for esm conditions
* refactor(cli): remove -c alias for --conditions flag
* test: add cases for multiple --conditions specified
* test(bundler): add support to test --conditions
* chore(cli): fix grammar mistakes in --conditions
---------
Co-authored-by: Jarred Sumner <jarred@jarredsumner.com>
* windows: pass test/js/web/timers/setTimeout.test.js
* gotta go fast
* ci: windows: try reverting this line
reproducibly getting:
Error: Unable to download artifact(s): Artifact not found for name: bun-windows-x64-zig
* ci: switch back to namespace for zig build
* Use namespace.so for faster CI
* arm64 runners arent working
* deflake
* more
* Update bun-mac-x64-baseline.yml
---------
Co-authored-by: Jarred Sumner <709451+Jarred-Sumner@users.noreply.github.com>
* okaaaaaaaay
* Revert "resolver: fix debug mode crash in test/bundler/bun-build-api.test.ts (#9140)"
This reverts commit 331d079dad.
* correctly fix the cache bust bug
this was introduced a couple of commits ago in my random fixes,
where i put the wrong fix to another directory caching bug.
i still stand by the assertion in place despite it causing many people
issues. it's precense will prevent subtle module resolutions failures.
* add an extra comment
* fix building a release build locally
* add a better test case for 3216
* staging
* fix mac issues
* ok
---------
Co-authored-by: Jarred Sumner <jarred@jarredsumner.com>
* fix 9118
* update
* RELEASE_AND_RETURN
* cache and coerce
* test for toContainKey throwing in hasOwnProperty
* fix test
* [autofix.ci] apply automated fixes
* fix non-truthy and more test
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
* Add test for ensuring the 'readable' event is emitted on end
* Run emitReadable on nextTick instead of as microtask
* perf: Store intermediate variables
Co-authored-by: Jarred Sumner <jarred@jarredsumner.com>
---------
Co-authored-by: Jarred Sumner <jarred@jarredsumner.com>
* Open with proper perms when redirecting file to stdin
* Add test for redirecting file to stdin
* Extract redirect flags -> bun.Mode logic to function
* Remove dead code
* Support duplicating output file descriptors
* Clean up
* fix merge fuck up
* Add comment documenting weird hack to get around ordering of posix spawn actions
* Update docs
* Delete dead code
* Update docs
* fix(ws/client): handle short reads on payload frame length
In the WebSocket specification, control frames may not be fragmented.
However, the frame parser should handle fragmented control frames
nonetheless. Whether or not the frame parser is given a set of
fragmented bytes to parse is subject to the strategy in which the client
buffers received bytes.
All stages of the frame parser currently supports parsing frames
fragmented across multiple TCP segments except for the payload frame
length parsing stage.
This commit implements buffering the bytes of a frame's payload length
into a client instance so that the websocket client is able to properly
parse payload frame lengths despite there being a short read over
incoming TCP data.
A test is added to
test/js/web/websocket/websocket-client-short-read.test.ts which creates
a make-shift WebSocket server that performs short writes over a single
WebSocket frame. The test passes with this commit.
* [autofix.ci] apply automated fixes
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
* Add `BUN_DEBUG` flag to control where debug logs go
* Update all the actions
* Configure temp
* use spawn instead of rm
* Use CLOSE_RANGE_CLOEXEC
* Make some tests more reproducible
* Update hot.test.ts
* Detect file descriptor leaks and wait for stdout
* Update runner.node.mjs
* Update preload.ts
---------
Co-authored-by: Jarred Sumner <709451+Jarred-Sumner@users.noreply.github.com>
* Open with proper perms when redirecting file to stdin
* Add test for redirecting file to stdin
* Extract redirect flags -> bun.Mode logic to function
* Remove dead code
* [autofix.ci] apply automated fixes
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
* windows: implement bun.isWritable
* windows: pass test/cli/run/as-node.test.ts
C:\Users\dave\AppData\Local\Temp\bun-node-a2ae984c3\node.exe is a hardlink on windows so it will not resolve to C:\bun\build\bun-debug.exe
skip the first param since that is not the behavior this test is supposed to be testing
* windows: pass test/js/node/dns/node-dns.test.js
* windows: pass test/js/node/process/process.test.js
* windows: pass test/js/web/streams/streams.test.js
* windows: pass test/js/workerd/html-rewriter.test.js
Closes#8459
* windows: fix node:util.inspect
* windows: these pass now
* windows: pass test/js/node/stream/node-stream.test.js
* disable http sendfile on windows
* use url.origin here
* more sendfile removal
* windows: pass test/js/web/websocket/websocket.test.js
* test/js/deno/performance/performance.test.ts is flaky, come back to it
---------
Co-authored-by: Jarred Sumner <jarred@jarredsumner.com>
