Open tisonkun opened 12 months ago
Here is a monkey patch for fix:
diff --git a/test/number-coercion-methods.spec.js b/test/number-coercion-methods.spec.js
index af299e68d..81d03ee25 100644
--- a/test/number-coercion-methods.spec.js
+++ b/test/number-coercion-methods.spec.js
@@ -89,7 +89,10 @@ describe('number coercion methods', () => {
);
}
}
- const neg = isToLength ? 0 : -value;
+ let neg = isToLength ? 0 : -value;
+ if (neg === 0) {
+ neg = 0;
+ }
return [value, value, neg, neg];
});
@@ -134,7 +137,12 @@ describe('number coercion methods', () => {
n = Math.min(n, isToLength ? MAX_ARRAY_LENGTH : MAX_SAFE_INTEGER);
}
}
- const neg = isToLength ? 0 : -n;
+ let neg = isToLength ? 0 : -n;
+ if (Number.isNaN(neg)) {
+ neg = Number.NaN;
+ } else if (neg === 0) {
+ neg = 0;
+ }
return [n, n, n, n, n, n, neg, neg];
});
It's a bun issue! I'll report it and link back ASAP.
Actually bun is more correct here. We want to side with bun here and respect -0
if our APIs produce it.
In bun if I do:
import { expect, test } from 'bun:test';
test('woo', () => {
expect([-0]).toEqual([-0]) // pass
});
but
expect([0]).toEqual([-0]) // fail
So bun seems to respect -0 :tada
@jdalton Sounds like we should update the test to follow the expected manner. If so, I can apply the patch above for doing so.
I don't know whether it's a
bun
issue. cc @jdaltonOr it can be a jest issue.