### What does this PR do?
Sometimes packages will use very large numbers exceeding max u32 for
major/minor/patch (usually patch). This pr changes each core number in
bun to u64.
Because we serialize package information to disk for the binary lockfile
and package manifests, this pr bumps the version of each. We don't need
to change anything other than the version for serialized package
manifests because they will invalidate and save the new version. For old
binary lockfiles, this pr adds logic for migrating to the new version.
Even if there are no changes, migrating will always save the new
lockfile. Unfortunately means there will be a one time invisible diff
for binary lockfile users, but this is better than installs failing to
work.
fixes#22881fixes#21793fixes#16041fixes#22891
resolves BUN-7MX, BUN-R4Q, BUN-WRB
### How did you verify your code works?
Manually, and added a test for migrating from an older binary lockfile.
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
### What does this PR do?
This PR does two things.
First, it fixes a bug when using
[`jest-dom`](https://github.com/testing-library/jest-dom) where
expectation failures would break as `RECEIVED_COLOR` and
`EXPECTED_COLOR` are not properties of `ExpectMatcherContext`.
<img width="1216" height="139" alt="image"
src="https://github.com/user-attachments/assets/26ef87c2-f763-4a46-83a3-d96c4c534f3d"
/>
Second, it adds some existing timer mock functions that were missing
from the `vi` object.
### How did you verify your code works?
I've added a test.
### What does this PR do?
### How did you verify your code works?
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Co-authored-by: Claude Bot <claude-bot@bun.sh>
## Summary
Implements `--cpu` and `--os` flags for `bun install` to filter optional
dependencies based on target architecture and operating system. This
allows developers to control which platform-specific optional
dependencies are installed.
## What Changed
### Core Implementation
- Added `--cpu` and `--os` flags to `bun install` command that accept
multiple values
- Multiple values combine with bitwise OR (e.g., `--cpu x64 --cpu arm64`
matches packages for either architecture)
- Updated `isDisabled` methods throughout the codebase to accept custom
CPU/OS targets
- Removed deprecated `isMatch` methods in favor of `isMatchWithTarget`
for consistency
### Files Modified
- `src/install/npm.zig` - Removed `isMatch` methods, standardized on
`isMatchWithTarget`
- `src/install/PackageManager/CommandLineArguments.zig` - Parse and
validate multiple flag values
- `src/install/PackageManager/PackageManagerOptions.zig` - Pass CPU/OS
options through
- `src/install/lockfile/Package.zig` & `Package/Meta.zig` - Updated
`isDisabled` signatures
- `src/install/lockfile/Tree.zig` & `lockfile.zig` - Updated call sites
## Usage Examples
```bash
# Install only x64 dependencies
bun install --cpu x64
# Install dependencies for both x64 and arm64
bun install --cpu x64 --cpu arm64
# Install Linux-specific dependencies
bun install --os linux
# Install for multiple platforms
bun install --cpu x64 --cpu arm64 --os linux --os darwin
```
## Test Plan
✅ All 10 tests pass in `test/cli/install/bun-install-cpu-os.test.ts`:
- CPU architecture filtering
- OS filtering
- Combined CPU and OS filtering
- Multiple CPU architectures support
- Multiple operating systems support
- Multiple CPU and OS combinations
- Error handling for invalid values
- Negated CPU/OS support (`!arm64`, `!linux`)
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: Jarred Sumner <jarred@jarredsumner.com>
### What does this PR do?
#22534 made `--test-name-pattern` more logical and not start with empty
` ` (space), so fixing the built regex to make it work still for old and
new bun
The other main issue that that pr did was make start events for filtered
out names which means it appears to rerun them all even when in reality
it doesn't as they are skipped
Also in theory with concurrent test, if there's an error after another
started it would be assigned to the wrong test because we don't get test
id's in the error event, so its just assumed its from the last started
one which with parallel means it isn't correct.
### How did you verify your code works?
