refactor(SplitterPanel): replace overflow:hidden with min-size: 0

[johnleider]

Why

dd7fed85 restored overflow: hidden on SplitterPanel to fix the playground's infinite vertical growth. That works because CSS Flexbox §4.5 says: when an item's overflow is anything other than visible, the implied minimum size becomes 0 instead of its min-content size. Without that, content like the playground's editor-container { height: calc(100% + 1px) !important } forces the panel's min-height past its flex-basis, and ResizeObservers turn it into a feedback loop.

The trouble: overflow: hidden bundles two effects.

Effect	Type
Suppresses flex implied min-size	structural (load-bearing)
Clips child content at panel edge	visual (consumer-facing)

Headless components shouldn't ship the second one. Tooltips, focus rings, drop shadows, popovers anchored inside a panel — all reasonable consumer needs that overflow: hidden quietly forbids.

What

Replace overflow: 'hidden' with minWidth: 0; minHeight: 0 in the panel's inline structural style.

 :style="[attrs.style, slotProps.attrs.style, {
   flexGrow: 0,
   flexShrink: 0,
   flexBasis: `${size}%`,
-  overflow: 'hidden',
+  minWidth: 0,
+  minHeight: 0,
 }]"

Per the Flexbox spec, an explicit min-size: 0 on the main axis short-circuits the implied-minimum rule the same way overflow: hidden does — but without clipping. Setting both axes covers horizontal and vertical splitters and protects against cross-axis overflow contributing back to the container.

Verification

• Playground: panels stable at 752/451/301px across a 5s window, identical to the overflow: hidden baseline. Editor container 397px, repl 396px, body 800px = viewport.
• All Splitter tests pass (83 tests).
• pnpm lint:fix, pnpm typecheck, pnpm test:run clean. Pre-push gauntlet (repo:knip + repo:sherif) clean.

Notes

Draft because:

1. Worth a second pair of eyes on the Flexbox spec interpretation — specifically that min-width: 0; min-height: 0 is fully equivalent to overflow: hidden for breaking the implied-minimum loop.
2. Possible follow-up: the playground's calc(100% + 1px) !important workaround in PlaygroundEditor.vue:97 is the originating trigger. Worth tracing that 1px's history — likely a Monaco scrollbar artifact — and removing it if no longer needed.

[pkg-pr-new]

Open in StackBlitz

commit: 751e5dc