fix(documents.js): replace rotationsOf's equivalent kind check with a property-presence guard

rotationsOf's vector.kind === "line" comparison was a genuine equivalent-
mutant trap: forcing that comparison to always-true still type-narrows on
the original condition text, so accessing rotationDeg in that branch
stays valid, and a line vector's own missing key reports undefined
either way -- indistinguishable from the correct branch's own explicit
undefined, so no test could ever kill it. A "rotationDeg" in vector check
narrows identically for every real input but has no such loophole: an
always-true mutation of it fails to compile outright (accessing
rotationDeg on the now-unnarrowed union), leaving only an always-false
mutation, which a real rotationDeg value does kill.

withoutRotation's own analogous survivors were a toEqual gap rather than
an equivalent mutant: spreading an explicit rotationDeg: undefined onto a
line vector (which never carries that key at all) still toEqual's the
untouched original, since toEqual treats an undefined-valued key as
indistinguishable from an absent one. toStrictEqual does not.

Author: Mearman

packages/documents.js/src/test-support/vectors.test.ts

@@ -0,0 +1,39 @@
+import type { ContentVector } from "document-schema.js";
+import { describe, expect, it } from "vitest";
+import { rotationsOf, withoutRotation } from "./vectors";
+
+const rect: ContentVector = {
+  kind: "rect",
+  frame: { xPt: 0, yPt: 0, widthPt: 10, heightPt: 10 },
+  rotationDeg: 30,
+};
+
+const line: ContentVector = {
+  kind: "line",
+  from: { xPt: 0, yPt: 0 },
+  to: { xPt: 10, yPt: 10 },
+  stroke: { widthPt: 1, color: { r: 0, g: 0, b: 0 } },
+};
+
+describe("withoutRotation", () => {
+  it("strips rotationDeg from a non-line vector", () => {
+    expect(withoutRotation([rect])).toEqual([
+      { ...rect, rotationDeg: undefined },
+    ]);
+  });
+
+  it("leaves a line vector, which has no rotationDeg field at all, untouched -- not spread with an explicit rotationDeg: undefined key added", () => {
+    // toStrictEqual, not toEqual: toEqual treats an explicit `rotationDeg: undefined` key as indistinguishable from the key being absent altogether, which is exactly the difference this test needs to catch.
+    expect(withoutRotation([line])).toStrictEqual([line]);
+  });
+});
+
+describe("rotationsOf", () => {
+  it("reports a non-line vector's own rotationDeg", () => {
+    expect(rotationsOf([rect])).toEqual([30]);
+  });
+
+  it("reports undefined for a line, positionally", () => {
+    expect(rotationsOf([rect, line])).toEqual([30, undefined]);
+  });
+});

packages/documents.js/src/test-support/vectors.ts

@@ -80,11 +80,11 @@ export function withoutRotation(
   );
 }
 
-// The rotations withoutRotation drops, positionally. 'line' has no rotationDeg on ContentVectorSchema at all, so it always reports undefined here.
+// The rotations withoutRotation drops, positionally. A property-presence check ("rotationDeg" in vector), not a vector.kind === "line" comparison: 'line' is the only variant lacking rotationDeg, so the two guards narrow identically -- but a kind comparison here is a genuine equivalent-mutant trap TypeScript itself cannot rescue: forcing that comparison's own condition to always-true still type-narrows on the ORIGINAL condition text, so `vector.rotationDeg` stays valid in the branch reached, and a 'line' object with no such key simply reports undefined either way, indistinguishable from the correct branch's own explicit undefined. The `in` check has no such loophole -- Stryker's own typescript-checker rejects an always-true mutation of it outright (accessing rotationDeg on the still-fully-widened union fails to compile), leaving only an always-false mutation, which a real rotationDeg value on a non-line vector does kill.
 export function rotationsOf(
   vectors: readonly ContentVector[],
 ): (number | undefined)[] {
   return vectors.map((vector) =>
-    vector.kind === "line" ? undefined : vector.rotationDeg,
+    "rotationDeg" in vector ? vector.rotationDeg : undefined,
   );
 }