- Replace std.json.stringifyAlloc with bun.JSON.toAST approach
- Use BufferWriter for proper JSON printing in graph visualizer
- Maintains compatibility with Bun's JSON handling infrastructure
🤖 Generated with Claude Code
Co-Authored-By: Claude <noreply@anthropic.com>
Fixed memory safety issue:
- ASAN detected use-after-poison when concatenating JavaScript output
- The compile_results_for_chunk memory was being accessed after deallocation
- Now make defensive copies of code immediately to avoid use-after-free
- Safely collect parts first, then concatenate if needed
Enhanced HTML visualizer to display new debugging data:
- Added panels for duplicate exports, symbol chains, and export details
- Show duplicate exports prominently with red warnings
- Display symbol resolution chains with color-coded link types
- Highlight ambiguous exports and conflicts
- Expanded symbol panel width to 400px for better visibility
- Added proper visualization of resolved exports
The debugger now provides complete visibility for:
- Duplicate export detection with file sources
- Symbol flow through import/export chains
- Ambiguous export warnings
- Full symbol resolution paths
- Export name to symbol mappings
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
Enhanced symbol tracking and debugging capabilities:
- Track actual export names with original symbol names
- Capture full symbol metadata including namespace aliases
- Add symbol chain tracking to follow resolution paths
- Track resolved exports with ambiguity detection
- Identify duplicate exports and conflicts
- Build complete symbol resolution chains
- Track re-exports and their targets
- Include all symbol flags for debugging
New data structures:
- SymbolChain: Tracks how symbols flow through imports/exports
- ChainLink: Individual steps in symbol resolution
- ResolvedExportInfo: Full export resolution data
- Enhanced ExportInfo with original names and locations
This provides comprehensive debugging for:
- Duplicate export issues
- Symbol resolution problems
- Import/export chain analysis
- Namespace merging conflicts
- Cross-file symbol tracking
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Remove generateMockSource() and generateMockOutput() functions
- Show "No source/output available" messages instead of fake data
- Remove 500/1000 char truncation limits - capture full source and output
- Concatenate all JavaScript compile results for complete output
- Default to 'after_generation' stage which has output code
- Only show real data from the bundler, no placeholders
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
The visualizer now fully works with:
- Actual source code snippets from input files (500 chars)
- Real JavaScript output from bundled chunks (1000 chars)
- New 'after_generation' stage that captures output after compilation
- HTML displays real source and output side-by-side
- Both visualizers generated: graph and code flow
To use:
1. Set BUN_BUNDLER_GRAPH_DUMP=all when bundling
2. Open code_flow_*.html from /tmp/bun-bundler-debug/
3. Load the after_generation JSON to see source→output transformation
Example:
env BUN_BUNDLER_GRAPH_DUMP=all bun build app.js --target=browser
The code flow visualizer shows actual code transformations, while the
graph visualizer shows the overall bundle structure.
Tested and working with multi-file bundles showing real transformations.
- Capture first 1000 chars of JavaScript output from compile_results_for_chunk
- Include source code snippets (first 500 chars) in FileData
- Add placeholders for source mappings extraction
- Both visualizers now generated: graph_visualizer.html and code_flow_visualizer.html
The code flow visualizer now has access to:
- Actual source code snippets from input files
- Real output code from bundled chunks
- Foundation for connecting symbols between source and output
Next steps:
- Fix JSON generation issues if any
- Parse source mappings to connect exact symbol positions
- Draw visual arrows between transformed symbols
- Show side-by-side diffs of transformations
This new visualizer provides what's actually needed for debugging:
- Split-pane view showing source code and output code side-by-side
- Source snippets included in JSON dumps (first 500 chars)
- Placeholders for output snippets and source mappings
- Stage comparison to see what changes between bundler phases
- CodeMirror editors for syntax-highlighted code viewing
- Symbol flow tracking between source and output
- Foundation for overlaying transformations on actual code
The original graph visualizer is still generated for high-level analysis,
while the new code_flow visualizer focuses on the actual code transformations.
Next steps would be:
- Capture actual output code from compile results
- Extract and include source mappings
- Show real symbol transformations with arrows
- Highlight exact symbol locations in code
- Fix symbols list: use source.symbols instead of source.samples
- Fix duplicate event listener memory leak by removing old listeners before adding new ones
- Implement cross-chunk imports edge visualization
- Preserve search field values when replacing elements
- Add cross_chunk_imports details (not just count)
- Include import records and declared symbols for each part
- Add symbol linking information with use counts and flags
- Include runtime metadata (file counts, css/html detection)
- Fix missing dagre library in HTML visualizer
- Fix field name mismatches between JSON and HTML (snake_case)
- Add chunk metadata (unique_key, final_path, content_type)
This provides much more detailed information for debugging bundler issues,
especially for tracking duplicate exports and understanding symbol resolution.
- Changed camelCase to snake_case to match JSON output
- Fixed field names: total_files, reachable_files, imports_and_exports, etc.
- Fixed accessing chunks properties: is_entry_point, files_in_chunk
- Fixed symbols structure: by_source instead of bySource
- Fixed imports target_source field name
All field accesses now correctly match the actual JSON structure produced.
🤖 Generated with Claude Code
Co-Authored-By: Claude <noreply@anthropic.com>
- Implements GraphVisualizer that dumps complete LinkerContext state to JSON
- Captures files, symbols, imports/exports, chunks, parts, and dependency graph
- Controlled via BUN_BUNDLER_GRAPH_DUMP environment variable (all/scan/chunks/compute/link)
- Uses proper bun.json.toAST and js_printer.printJSON for correct JSON serialization
- Enhanced json.toAST to support custom toExprForJSON methods and BabyList-like types
- Includes interactive D3.js HTML visualizer with multiple views
- Helps debug duplicate exports, circular dependencies, and bundling issues
- Outputs to /tmp/bun-bundler-debug/ with timestamped files
Usage: BUN_BUNDLER_GRAPH_DUMP=all bun build file.js
🤖 Generated with Claude Code
Co-Authored-By: Claude <noreply@anthropic.com>
Replace `catch bun.outOfMemory()`, which can accidentally catch
non-OOM-related errors, with either `bun.handleOom` or a manual `catch
|err| switch (err)`.
(For internal tracking: fixes STAB-1070)
---------
Co-authored-by: Dylan Conway <dylan.conway567@gmail.com>
### What does this PR do?
- Implements .onEnd
Fixes#22061
Once #22144 is merged, this also fixes:
Fixes#9862Fixes#20806
### How did you verify your code works?
Tests
---
TODO in a followup (#22144)
> ~~Make all entrypoints be called in onResolve~~
> ~~Fixes # 9862~~
> ~~Fixes # 20806~~
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
### What does this PR do?
optimize advance method
after this optimizations
100k req the query bellow in 1 connection takes 792ms instead of 6s
```sql
SELECT CAST(1 AS UNSIGNED) AS x
```
1mi req of the query bellow with 10 connections takes 57.41s - 62.5s
instead of 162.50s, mysql2 takes 1516.94s for comparison
```sql
SELECT * FROM users_bun_bench LIMIT 100
```
### How did you verify your code works?
Tested and benchmarked + CI
For jest compatibility. Fixes#5228
---------
Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
### What does this PR do?
fixes parsing strings like `"1e18495d9d7f6b41135e5ee828ef538dc94f9be4"`
### How did you verify your code works?
added a test.
## Summary
Fixes a bug in the internal `bun.spawnSync` implementation where
stderr's poll file descriptor was incorrectly set to stdout's fd when
polling both streams.
## The Bug
In `/src/bun.js/api/bun/process.zig` line 2204, when setting up the poll
file descriptor array for stderr, the code incorrectly used
`out_fds_to_wait_for[0]` (stdout) instead of `out_fds_to_wait_for[1]`
(stderr).
This meant:
- stderr's fd was never actually polled
- stdout's fd was polled twice
- Could cause stderr data to be lost or incomplete
- Could potentially cause hangs when reading from stderr
## Impact
This bug only affects Bun's internal CLI commands that use
`bun.spawnSync` with both stdout and stderr piped (like `bun create`,
`bun upgrade`, etc.). The JavaScript `spawnSync` API uses a different
code path and is not affected.
## The Fix
Changed line 2204 from:
```zig
poll_fds[poll_fds.len - 1].fd = @intCast(out_fds_to_wait_for[0].cast());
```
to:
```zig
poll_fds[poll_fds.len - 1].fd = @intCast(out_fds_to_wait_for[1].cast());
```
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: Claude <noreply@anthropic.com>
## Summary
Fixes an issue where `--compile-exec-argv` options were incorrectly
appearing in `process.argv` when no user arguments were provided to a
compiled standalone binary.
## Problem
When building a standalone binary with `--compile-exec-argv`, the exec
argv options would leak into `process.argv` when running the binary
without any user arguments:
```bash
# Build with exec argv
bun build --compile-exec-argv="--user-agent=hello" --compile ./a.js
# Run without arguments - BEFORE fix
./a
# Output showed --user-agent=hello in both execArgv AND argv (incorrect)
{
execArgv: [ "--user-agent=hello" ],
argv: [ "bun", "/$bunfs/root/a", "--user-agent=hello" ], # <- BUG: exec argv leaked here
}
# Expected behavior (matches runtime):
bun --user-agent=hello a.js
{
execArgv: [ "--user-agent=hello" ],
argv: [ "/path/to/bun", "/path/to/a.js" ], # <- No exec argv in process.argv
}
```
## Solution
The issue was in the offset calculation for determining which arguments
to pass through to the JavaScript runtime. The offset was being
calculated before modifying the argv array with exec argv options,
causing it to be incorrect when the original argv only contained the
executable name.
The fix ensures that:
- `process.execArgv` correctly contains the compile-exec-argv options
- `process.argv` only contains the executable, script path, and user
arguments
- exec argv options never leak into `process.argv`
## Test plan
Added comprehensive tests to verify:
1. Exec argv options don't leak into process.argv when no user arguments
are provided
2. User arguments are properly passed through when exec argv is present
3. Existing behavior continues to work correctly
All tests pass:
```
bun test compile-argv.test.ts
✓ 3 tests pass
```
🤖 Generated with [Claude Code](https://claude.ai/code)
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
This PR adds `Bun.secrets`, a new API for securely storing and
retrieving credentials using the operating system's native credential
storage locally. This helps developers avoid storing sensitive data in
plaintext config files.
```javascript
// Store a GitHub token securely
await Bun.secrets.set({
service: "my-cli-tool",
name: "github-token",
value: "ghp_xxxxxxxxxxxxxxxxxxxx"
});
// Retrieve it when needed
const token = await Bun.secrets.get({
service: "my-cli-tool",
name: "github-token"
});
// Use with fallback to environment variable
const apiKey = await Bun.secrets.get({
service: "my-app",
name: "api-key"
}) || process.env.API_KEY;
```
Marking this as a draft because Linux and Windows have not been manually
tested yet. This API is only really meant for local development usecases
right now, but it would be nice if in the future to support adapters for
production or CI usecases.
### Core API
- `Bun.secrets.get({ service, name })` - Retrieve a stored credential
- `Bun.secrets.set({ service, name, value })` - Store or update a
credential
- `Bun.secrets.delete({ service, name })` - Delete a stored credential
### Platform Support
- **macOS**: Uses Keychain Services via Security.framework
- **Linux**: Uses libsecret (works with GNOME Keyring, KWallet, etc.)
- **Windows**: Uses Windows Credential Manager via advapi32.dll
### Implementation Highlights
- Non-blocking - all operations run on the threadpool
- Dynamic loading - no hard dependencies on system libraries
- Sensitive data is zeroed after use
- Consistent API across all platforms
## Use Cases
This API is particularly useful for:
- CLI tools that need to store authentication tokens
- Development tools that manage API keys
- Any tool that currently stores credentials in `~/.npmrc`,
`~/.aws/credentials` or in environment variables that're globally loaded
## Testing
Comprehensive test suite included with coverage for:
- Basic CRUD operations
- Empty strings and special characters
- Unicode support
- Concurrent operations
- Error handling
All tests pass on macOS. Linux and Windows implementations are complete
but would benefit from additional platform testing.
## Documentation
- Complete API documentation in `docs/api/secrets.md`
- TypeScript definitions with detailed JSDoc comments and examples
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
### What does this PR do?
This PR adds builtin YAML parsing with `Bun.YAML.parse`
```js
import { YAML } from "bun";
const items = YAML.parse("- item1");
console.log(items); // [ "item1" ]
```
Also YAML imports work just like JSON and TOML imports
```js
import pkg from "./package.yaml"
console.log({ pkg }); // { pkg: { name: "pkg", version: "1.1.1" } }
```
### How did you verify your code works?
Added some tests for YAML imports and parsed values.
---------
Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Co-authored-by: Jarred Sumner <jarred@jarredsumner.com>
* `IncrementalGraph(.client).File` packs its fields in a specific way to
save space, but it makes the struct hard to use and error-prone (e.g.,
untagged unions with tags stored in a separate `flags` struct). This PR
changes `File` to have a human-readable layout, but adds methods to
convert it to and from `File.Packed`, a packed version with the same
space efficiency as before.
* Reduce the need to pass the dev allocator to functions (e.g.,
`deinit`) by storing it as a struct field via the new `DevAllocator`
type. This type has no overhead in release builds, or when
`AllocationScope` is disabled.
* Use owned pointers in `PackedMap`.
* Use `bun.ptr.Shared` for `PackedMap` instead of the old
`bun.ptr.RefPtr`.
* Add `bun.ptr.ScopedOwned`, which is like `bun.ptr.Owned`, but can
store an `AllocationScope`. No overhead in release builds or when
`AllocationScope` is disabled.
* Reduce redundant allocators in `BundleV2`.
* Add owned pointer conversions to `MutableString`.
* Make `AllocationScope` behave like a pointer, so it can be moved
without invalidating allocations. This eliminates the need for
self-references.
* Change memory cost algorithm so it doesn't rely on “dedupe bits”.
These bits used to take advantage of padding but there is now no padding
in `PackedMap`.
* Replace `VoidFieldTypes` with `useAllFields`; this eliminates the need
for `voidFieldTypesDiscardHelper`.
(For internal tracking: fixes STAB-1035, STAB-1036, STAB-1037,
STAB-1038, STAB-1039, STAB-1040, STAB-1041, STAB-1042, STAB-1043,
STAB-1044, STAB-1045)
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Co-authored-by: Jarred Sumner <jarred@jarredsumner.com>
Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
## Summary
Fixes an assertion failure that occurred when `server.stop()` was called
while HTTP requests were still in flight.
## Root Cause
The issue was in `jsValueAssertAlive()` at
`src/bun.js/api/server.zig:627`, which had an assertion requiring
`server.listener != null`. However, `server.stop()` immediately sets
`listener` to null, causing assertion failures when pending requests
triggered callbacks that accessed the server's JavaScript value.
## Solution
Converted the server's `js_value` from `jsc.Strong.Optional` to
`jsc.JSRef` for safer lifecycle management:
- **On `stop()`**: Downgrade from strong to weak reference instead of
calling `deinit()`
- **In `finalize()`**: Properly call `deinit()` on the JSRef
- **Remove problematic assertion**: JSRef allows safe access to JS value
via weak reference even after stop
## Benefits
- ✅ No more assertion failures when stopping servers with pending
requests
- ✅ In-flight requests can still access the server JS object safely
- ✅ JS object can be garbage collected when appropriate
- ✅ Maintains backward compatibility - no external API changes
## Test plan
- [x] Reproduces the original assertion failure
- [x] Verifies the fix resolves the issue
- [x] Adds regression test to prevent future occurrences
- [x] Confirms normal server functionality still works
The fix includes a comprehensive regression test at
`test/regression/issue/server-stop-with-pending-requests.test.ts`.
🤖 Generated with [Claude Code](https://claude.ai/code)
---------
Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Co-authored-by: Jarred Sumner <jarred@jarredsumner.com>
easy fix to https://x.com/kiritotwt1/status/1958452541718458513/photo/1
as it's generated of the types so should be accurate documentation. in
future it could be better done like what it may have been once upon a
time
(this doesn't fix the error, but it fixes the broken link)
## Summary
- Implement `Symbol.asyncDispose` for the `Worker` class in
`worker_threads` module
- Enables automatic resource cleanup with `await using` syntax
- Calls `await this.terminate()` to properly shut down workers when they
go out of scope
## Implementation Details
The implementation adds a simple async method to the Worker class:
```typescript
async [Symbol.asyncDispose]() {
await this.terminate();
}
```
This allows workers to be used with the new `await using` syntax for
automatic cleanup:
```javascript
{
await using worker = new Worker('./worker.js');
// worker automatically terminates when leaving this scope
}
```
## Test Plan
- [x] Added comprehensive tests for `Symbol.asyncDispose` functionality
- [x] Tests verify the method exists and returns undefined
- [x] Tests verify `await using` syntax works correctly for automatic
worker cleanup
- [x] All new tests pass
- [x] Existing worker_threads functionality remains intact
🤖 Generated with [Claude Code](https://claude.ai/code)
---------
Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Followup to #22049: I'm pretty sure “platform-specific padding” on
Windows is a hallucination. I think this is due to ReleaseSafe adding
tags to untagged unions.
(For internal tracking: fixes STAB-1057)
### What does this PR do?
Support the following:
```javascript
const nom = await sql`SELECT name FROM food WHERE category IN ${sql(['bun', 'baozi', 'xiaolongbao'])}`;
```
Previously, only e.g., `sql([1, 2, 3])` was supported.
To be honest I'm not sure what the semantics of SQLHelper *ought* to be.
I'm pretty sure objects ought to be auto-inferred. I'm not sure about
arrays, but given the rest of the code in `SQLHelper` trying to read the
tea leaves on stringified numeric keys I figured someone cared about
this use case. I don't know about other types, but I'm pretty sure that
`Object.keys("bun") === [0, 1, 2]` is an oversight and unintended.
(Incidentally, the reason numbers previously worked is because
`Object.keys(4) === []`). I decided that all non-objects and non-arrays
should be treated as not having auto-inferred columns.
Fixes#18637
### How did you verify your code works?
I wrote a test, but was unable to run it (or any other tests in this
file) locally due to Docker struggles. I sure hope it works!
### What does this PR do?
This PR fixes https://github.com/oven-sh/bun/issues/19131.
I am not 100% certain that this fix is correct as I am still nebulous
regarding some decisions I've made in this PR. I'll try to provide my
reasoning and would love to be proven wrong:
#### Re-authentication
- The `is_authenticated` flag needs to be reset to false. When the
lifecycle reaches a point of attempting to connect, it sends out a
`HELLO 3`, and receives a response. `handleResponse()` is fired and does
not correctly handle it because there is a guard at the top of the
function:
```zig
if (!this.flags.is_authenticated) {
this.handleHelloResponse(value);
// We've handled the HELLO response without consuming anything from the command queue
return;
}
```
Rather, it treats this packet as a regular data packet and complains
that it doesn't have a promise to associate it to. By resetting the
`is_authenticated` flag to false, we guarantee that we handle the `HELLO
3` packet as an authentication packet.
It also seems to make semantic sense since dropping a connection implies
you dropped authentication.
#### Retry Attempts
I've deleted the `retry_attempts = 0` in `reconnect()` because I noticed
that we would never actually re-attempt to reconnect after the first
attempt. Specifically, I was expecting `valkey.zig:459` to potentially
fire multiple times, but it only ever fired once. Removing this reset to
zero caused successful reattempts (in my case 3 of them).
```zig
debug("reconnect in {d}ms (attempt {d}/{d})", .{ delay_ms, this.retry_attempts, this.max_retries });
```
I'm still iffy on whether this is necessary, but I think it makes sense.
```zig
this.client.retry_attempts = 0
```
### How did you verify your code works?
I have added a small unit test. I have compared mainline `bun`, which
fails that test, to this fix, which passes the test.
---------
Co-authored-by: Ciro Spaciari <ciro.spaciari@gmail.com>
## Summary
- Implements automated Windows code signing for x64 and x64-baseline
builds
- Integrates DigiCert KeyLocker for secure certificate management
- Adds CI/CD pipeline support for signing during builds
## Changes
- Added `.buildkite/scripts/sign-windows.sh` script for automated
signing
- Updated CMake configurations to support signing workflow
- Modified build scripts to integrate signing step
## Testing
- Script tested locally with manual signing process
- Successfully signed test binaries at:
- `C:\Builds\bun-windows-x64\bun.exe`
- `C:\Builds\bun-windows-x64-baseline\bun.exe`
## References
Uses DigiCert KeyLocker tools for Windows signing
## Next Steps
- Validate Buildkite environment variables in CI
- Test full pipeline in CI environment
---------
Co-authored-by: Jarred Sumner <jarred@bun.sh>
Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
### What does this PR do?
Fixes#20729
### How did you verify your code works?
There is a test
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
### What does this PR do?
Add MySQL support, Refactor will be in a followup PR
### How did you verify your code works?
A lot of tests
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Co-authored-by: cirospaciari <6379399+cirospaciari@users.noreply.github.com>
### What does this PR do?
Fixes#22014
todo:
- [x] not spawn sync
- [x] better comm to subprocess (not stderr)
- [x] tty
- [x] more tests (also include some tests for the actual implementation
of a provider)
- [x] disable autoinstall?
Scanner template: https://github.com/oven-sh/security-scanner-template
<!-- **Please explain what your changes do**, example: -->
<!--
This adds a new flag --bail to bun test. When set, it will stop running
tests after the first failure. This is useful for CI environments where
you want to fail fast.
-->
---
- [x] Documentation or TypeScript types (it's okay to leave the rest
blank in this case)
- [x] Code changes
### How did you verify your code works?
<!-- **For code changes, please include automated tests**. Feel free to
uncomment the line below -->
<!-- I wrote automated tests -->
<!-- If JavaScript/TypeScript modules or builtins changed:
- [ ] I included a test for the new code, or existing tests cover it
- [ ] I ran my tests locally and they pass (`bun-debug test
test-file-name.test`)
-->
<!-- If Zig files changed:
- [ ] I checked the lifetime of memory allocated to verify it's (1)
freed and (2) only freed when it should be
- [ ] I included a test for the new code, or an existing test covers it
- [ ] JSValue used outside of the stack is either wrapped in a
JSC.Strong or is JSValueProtect'ed
- [ ] I wrote TypeScript/JavaScript tests and they pass locally
(`bun-debug test test-file-name.test`)
-->
<!-- If new methods, getters, or setters were added to a publicly
exposed class:
- [ ] I added TypeScript types for the new methods, getters, or setters
-->
<!-- If dependencies in tests changed:
- [ ] I made sure that specific versions of dependencies are used
instead of ranged or tagged versions
-->
<!-- If a new builtin ESM/CJS module was added:
- [ ] I updated Aliases in `module_loader.zig` to include the new module
- [ ] I added a test that imports the module
- [ ] I added a test that require() the module
-->
tests (bad currently)
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Co-authored-by: Dylan Conway <dylan-conway@users.noreply.github.com>
Co-authored-by: Dylan Conway <dylan.conway567@gmail.com>
Co-authored-by: Jarred Sumner <jarred@jarredsumner.com>
