feat: migrate from pnpm/vitest to bun #89
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Replace pnpm with bun for package management and vitest with bun:test for testing. All 80 tests pass with bun's built-in test runner. Changes: - Test imports changed from vitest to bun:test (3 files) - package.json scripts: vitest → bun test, added typecheck script - CI workflows updated to use oven-sh/setup-bun - Removed vitest devDependency, added @types/bun - Deleted pnpm-lock.yaml (bun.lock already existed) Notes: - Bun has expectTypeOf built-in (vitest-compatible) - publish.yml keeps setup-node for npm registry auth (changesets uses npm)
…types Simplifies Result type discrimination by using error as the only discriminant: - error === null → Ok (data can be anything, including null) - error !== null → Err Changes: - Added EXPECTED_ERROR_NOT_NULL failure message - ErrSchema now checks error === null first - ResultSchema simplified: removed isErrVariant, renamed isOkVariant to isOk - Updated tests to reflect new validation behavior
…iminant With error as the sole discriminant, there's no 'invalid' Result state: - error === null → Ok (always) - error !== null → Err (always, regardless of data) Removed: - INVALID_RESULT check from ResultSchema - EXPECTED_DATA_NULL check from ErrSchema - isNeitherNull check from core isResult() function - Unused failure messages from failures.ts The Result type is now maximally simple: any object with data and error properties is valid, and error determines the variant.
Update documentation to reflect that error (not data) is the universal
discriminant for Result types. Data cannot be used reliably because it
can be null as a valid success value (Ok<null>).
Key clarifications:
- error === null → always Ok
- error !== null → always Err
- { data: null, error: null } is Ok<null> (tiebreaker rule)
- { data: x, error: x } is Err (error wins when both present)
…ecommendation Clarify that both data and error work as discriminants (symmetric), but recommend checking error by default since it handles all cases including Ok<null>. Added practical example showing the edge case. Changes based on documentation review feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Migrates from pnpm/vitest to bun for faster test execution and simpler tooling, plus refines the Result type discrimination model.
Tooling Changes:
Result Type Refinement:
Simplifies Result discrimination to use
erroras the primary discriminant:error === null→ Ok (always)error !== null→ Err (always){ data: null, error: null }→ Ok (tiebreaker: error wins){ data: "x", error: "x" }→ Err (error wins when both present)Both
dataanderrorwork as discriminants in most cases (they're symmetric), but we recommend checkingerrorby default since it handles all cases includingOk<null>.Documentation:
Updated docs to clarify the symmetric discriminant model with error-first recommendation.