Summary
fuseProps accepts any string as a connections key. A typo'd pin name — or a key that isn't a pin at all — passes validation silently, where every other component rejects it.
const typo = { pin99: ".R1 > .pin1" }
fuseProps.safeParse({ name: "F1", currentRating: "1A", connections: typo })
// → success: true ❌
capacitorProps.safeParse({ name: "C1", capacitance: "1uF", connections: typo })
// → success: false ✅
resistorProps.safeParse({ name: "R1", resistance: "1k", connections: typo })
// → success: false ✅A fuse is a two-pin passive exactly like a resistor or capacitor, so there's no reason for it to behave differently here.
Everything gets through:
connections |
result |
{ pin1: "..." } |
accepted (correct) |
{ pin99: "..." } |
accepted |
{ "not a pin at all": "..." } |
accepted |
{ "": "..." } |
accepted |
The empty-key case is worth calling out: "" isn't a selector, and downstream that produces an internal CSS-parser error rather than anything actionable (I filed that side of it as tscircuit/core#2865).
Cause
Two related gaps in lib/components/fuse.ts.
1. It hand-rolls the connections schema instead of using the shared helper. Every other component builds it from its own pin labels:
// capacitor.ts, resistor.ts, ...
connections: createConnectionsProp(capacitorPinLabels).optional(),
createConnectionsProp keys the record on z.enum(labels), so unknown keys fail. Fuse instead does:
// fuse.ts
connections: z
.record(z.string(), z.union([...])) // ← any key passes
.optional(),
The file already defines fusePinLabels = ["pin1", "pin2"] and exports it — it just isn't used for this.
2. Nothing checks the schema against the interface. FuseProps declares connections?: Connections<PinLabel> while the schema produces Record<string, ...>. That mismatch is exactly what expectTypesMatch exists to catch, and fuse is the only component in lib/components/ that exports both an interface and an Inferred* type without calling it. (I checked all 20 files that omit expectTypesMatch; the rest don't export both, so fuse is the single gap.)
Adding the check to the current file proves the drift:
error TS2345: Argument of type 'true' is not assignable to parameter of
type '"property connections has mismatched types"'.
So the invariant the repo relies on was never applied here, and the types silently diverged.
Expected
fuseProps should build connections from fusePinLabels like every other component, and the file should carry the expectTypesMatch assertion so this can't drift again.
PR follows.
Summary
fusePropsaccepts any string as aconnectionskey. A typo'd pin name — or a key that isn't a pin at all — passes validation silently, where every other component rejects it.A fuse is a two-pin passive exactly like a resistor or capacitor, so there's no reason for it to behave differently here.
Everything gets through:
connections{ pin1: "..." }{ pin99: "..." }{ "not a pin at all": "..." }{ "": "..." }The empty-key case is worth calling out:
""isn't a selector, and downstream that produces an internal CSS-parser error rather than anything actionable (I filed that side of it as tscircuit/core#2865).Cause
Two related gaps in
lib/components/fuse.ts.1. It hand-rolls the
connectionsschema instead of using the shared helper. Every other component builds it from its own pin labels:createConnectionsPropkeys the record onz.enum(labels), so unknown keys fail. Fuse instead does:The file already defines
fusePinLabels = ["pin1", "pin2"]and exports it — it just isn't used for this.2. Nothing checks the schema against the interface.
FusePropsdeclaresconnections?: Connections<PinLabel>while the schema producesRecord<string, ...>. That mismatch is exactly whatexpectTypesMatchexists to catch, and fuse is the only component inlib/components/that exports both an interface and anInferred*type without calling it. (I checked all 20 files that omitexpectTypesMatch; the rest don't export both, so fuse is the single gap.)Adding the check to the current file proves the drift:
So the invariant the repo relies on was never applied here, and the types silently diverged.
Expected
fusePropsshould buildconnectionsfromfusePinLabelslike every other component, and the file should carry theexpectTypesMatchassertion so this can't drift again.PR follows.