fix(Select,SelectMenu): add the fixed prop to hold the mobile text size

[IgorShevchik]

Ports e791d302 — the last of the four upstream commits in this queue, after #524 took the other three. Cursor moves to e791d302, which is nuxt/ui v4 HEAD, so the sync is caught up again.

What the prop is for

Input and InputMenu carry a fixed prop; Select and SelectMenu did not, so their text size could not be held at the mobile value.

The mechanism is easy to read backwards. iOS Safari zooms the page when a text control under 16px takes focus, so the mobile size is the larger one and a md: override steps it back down above the breakpoint. fixed drops that override, and the mobile size holds everywhere.

Component half — applies exactly

Both files carried upstream's pre-image (highlight?: boolean with no fixed after it; a tv() call with highlight: highlight.value and no fixed), so all three hunks land as written, including SelectMenu forwarding fixed into searchInputProps so the field inside the menu follows the same setting.

One deliberate wording change: this fork documents fixed on Input.vue and InputMenu.vue as "Keep the mobile text size on all breakpoints. (Left for backward compatibility.)". The parenthetical is not copied — on Select the prop is new rather than inherited, and carrying that note across would say something false about it.

Theme half — not taken, and taking it would be a regression

Upstream deletes base from all five size variants in select.ts so the base sizing falls through to the input theme it extends. Here that would break sizing, for two reasons established by measurement rather than by reading the theme:

We already inherit the responsive part. theme/select.ts extends input through defuFn, and the compound variants pairing fixed: false with each size come with it. The committed snapshots say so directly — Select carries md:text-(length:…) in 44 places and SelectMenu in 96, before this change. So the fork was never missing the responsive rule; it was missing the lever to switch it off, which is exactly what the component half adds.

Our base lines are not upstream's. They read h-[28px] gap-1.5 text-(length:--ui-font-size-xs)/[normal] — explicit heights and this fork's own font scale, one step off input's at several sizes — plus an xss size upstream has no equivalent of. Deleting them would change the height of every Select in the library.

Tests assert, rather than snapshot

The prop's whole effect is a class that is absent, and no snapshot moves: fixed defaults to unset, so the default render is unchanged. A snapshot case would pin the classes without stating what the prop is for, and would keep passing if the responsive rule stopped reaching Select altogether.

Three assertions per component instead:

responsive override present by default	md:text-(length:…) matches
gone with fixed	does not match
un-prefixed size class survives both ways	guards the obvious wrong fix — dropping the base size rather than the override would satisfy the second assertion while leaving the control with no size at all

Mutation-checked rather than assumed:

• removing fixed: props.fixed from both tv() calls — i.e. reverting the port — turns 2 red, exactly the two that pin the new behaviour;
• inverting it to !props.fixed turns 101 red, snapshots included, which confirms the wiring reaches rendered output rather than stopping at the props object.

Recorded, not fixed here

fixed on Input and InputMenu has no test at all and has been shipping uncovered since it was introduced. Out of scope for a port of a Select commit, but it is the same prop and the same mechanism, and the assertions above transfer directly. Written into .sync/log/e791d302….md so it is not lost.

Verification

lint · typecheck · build (3.86 MB) · test — 340 files, 7706 passed, 6 skipped · test:module.

---

Generated by Claude Code