feat: add fanout boundary padding props - #763
Merged
Merged
Conversation
seveibar
marked this pull request as ready for review
July 28, 2026 19:16
Comment on lines
+45
to
+71
| test("autorouting phase accepts scalar fanout boundary padding", () => { | ||
| const raw = { | ||
| autorouter: "fanout", | ||
| fanoutBoundaryPadding: "0.6mm", | ||
| } satisfies AutoroutingPhaseProps | ||
|
|
||
| expect(autoroutingPhaseProps.parse(raw).fanoutBoundaryPadding).toBe(0.6) | ||
| }) | ||
|
|
||
| test("autorouting phase accepts directional fanout boundary padding", () => { | ||
| const raw = { | ||
| autorouter: "fanout", | ||
| fanoutBoundaryPadding: { | ||
| top: "0.4mm", | ||
| right: 0.8, | ||
| bottom: "1.2mm", | ||
| left: 0.5, | ||
| }, | ||
| } satisfies AutoroutingPhaseProps | ||
|
|
||
| expect(autoroutingPhaseProps.parse(raw).fanoutBoundaryPadding).toEqual({ | ||
| top: 0.4, | ||
| right: 0.8, | ||
| bottom: 1.2, | ||
| left: 0.5, | ||
| }) | ||
| }) |
Contributor
There was a problem hiding this comment.
This file now contains more than one test(...) call. The rule states that a *.test.ts file may have AT MOST one test(...). The two new tests ('autorouting phase accepts scalar fanout boundary padding' and 'autorouting phase accepts directional fanout boundary padding') should be split into separate numbered files, e.g. autoroutingphase1.test.ts, autoroutingphase2.test.ts, etc., leaving at most one test per file.
Spotted by Graphite (based on custom rule: Custom rule)
Is this helpful? React 👍 or 👎 to let us know.
Contributor
|
Thank you for your contribution! 🎉 PR Rating: ⭐⭐ Track your contributions and see the leaderboard at: tscircuit Contribution Tracker |
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
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.
Summary
FanoutBoundaryPaddingsupporting a scalar distance or directional{ top, right, bottom, left }distancesfanoutBoundaryPaddingon both<breakout>and<autoroutingphase>@tscircuit/propsMotivation
The fanout solver needs a shared boundary around only the source footprint pads. Existing breakout
paddingcontrols the group/layout bounds around every child, so nearby destination footprints such as decoupling capacitors enlarge that boundary. This prop lets core/solver integration terminate fanout before those surrounding parts while leaving ordinary breakout layout padding unchanged.Directional fields allow asymmetric escape room. Omitted directional values are defined as zero. When the prop is absent, downstream implementations can retain automatic pitch-based boundary inference.
Proposed integration semantics
A subsequent fanout-solver/core change will resolve this padding against the union of source-pad bounds and pass the resulting shared boundary to the solver. When both are supplied, phase-level padding should override the breakout-level value.
Validation
bun test— 393 passedbun run typecheckbun run buildbun run check-circular-depsgit diff --check