Summary
Setting schTraceAutoLabelEnabled={false} on either a <group> or <board> element has no observable effect on the schematic output. The schematic placer continues to emit schematic_net_label elements for every node on a named net, regardless of the prop's value. Setting it on the parent group, the board, or both produces identical SVG output.
The prop typechecks via SubcircuitGroupProps.schTraceAutoLabelEnabled (described as "If true, net labels will automatically be created for complex traces"), so users assume false will suppress them. It doesn't.
Repro
export default () => (
<board width="20mm" height="20mm" schTraceAutoLabelEnabled={false}>
<chip
name="U1"
footprint="soic8"
pinLabels={{ pin1: "VCC", pin2: "GND" }}
connections={{ VCC: "net.V3_3", GND: "net.GND" }}
/>
<resistor
name="R1"
resistance="10k"
footprint="0402"
connections={{ pin1: "net.V3_3", pin2: "net.GND" }}
/>
</board>
)
tsci build
jq '[.[] | select(.type=="schematic_net_label")] | length' dist/index/circuit.json
# → ≥ 4 (V3_3 labels at U1.VCC, R1.pin1; GND labels at U1.GND, R1.pin2)
# Expected: 0 with schTraceAutoLabelEnabled={false}
The same script with the prop removed produces the same number of labels.
Why this matters
Named-net rendering as labels (instead of drawn wires) is the canonical tscircuit schematic style and matches commercial schematic conventions. So most users won't want to disable it. But:
- Users find this prop in the docs / type definitions and assume it does what it says.
- Some specific cases (single-page schematics with only a few power connections, certain didactic examples) genuinely benefit from drawn wires over labels — and the prop existing implies the override is supported.
- Silent no-ops are confusing; users assume the prop's value is fighting their other settings.
Suggested fix (any of)
- Implement — when
false, force the placer to draw schematic_trace elements for all source_traces on the affected group/board, even when the source_trace's net has multiple references. (Acknowledging that this can cause visual spaghetti for complex power nets — that's the user's choice.)
- Or warn: log when the prop is set but not yet implemented.
- Or remove from typings until implemented.
Hit while trying to make a decoupling cap chain visibly wire to the chip pin on a schematic — the cap chain shared net.V3_3 with the chip, so the placer rendered both endpoints as labels rather than drawing a connecting wire. Tried schTraceAutoLabelEnabled={false} as a documented escape hatch; no change. Eventually accepted that named nets rendering as labels is by design and there's no per-trace override — but the existence of this prop suggested otherwise.
Related: this gap is now documented in our project's docs/tscircuit-diagnostic-playbook.md so future sessions don't burn time on it.
Summary
Setting
schTraceAutoLabelEnabled={false}on either a<group>or<board>element has no observable effect on the schematic output. The schematic placer continues to emitschematic_net_labelelements for every node on a named net, regardless of the prop's value. Setting it on the parent group, the board, or both produces identical SVG output.The prop typechecks via
SubcircuitGroupProps.schTraceAutoLabelEnabled(described as "If true, net labels will automatically be created for complex traces"), so users assumefalsewill suppress them. It doesn't.Repro
The same script with the prop removed produces the same number of labels.
Why this matters
Named-net rendering as labels (instead of drawn wires) is the canonical tscircuit schematic style and matches commercial schematic conventions. So most users won't want to disable it. But:
Suggested fix (any of)
false, force the placer to drawschematic_traceelements for all source_traces on the affected group/board, even when the source_trace's net has multiple references. (Acknowledging that this can cause visual spaghetti for complex power nets — that's the user's choice.)Hit while trying to make a decoupling cap chain visibly wire to the chip pin on a schematic — the cap chain shared
net.V3_3with the chip, so the placer rendered both endpoints as labels rather than drawing a connecting wire. TriedschTraceAutoLabelEnabled={false}as a documented escape hatch; no change. Eventually accepted that named nets rendering as labels is by design and there's no per-trace override — but the existence of this prop suggested otherwise.Related: this gap is now documented in our project's
docs/tscircuit-diagnostic-playbook.mdso future sessions don't burn time on it.