FE-681: add multiselect to ds

[alex-e-leon]

🌟 What is the purpose of this PR?

• Adds multiple prop to select to enable multi select
• Adds searcheable prop to select

Pre-Merge Checklist 🚀

🚢 Has this modified a publishable library?

This PR:

• does not modify any publishable blocks or libraries, or modifications do not need publishing

📜 Does this require a change to the docs?

The changes in this PR:

• are internal and do not require a docs change

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
hash	Ready	Preview	Sep 7, 2026 7:52am UTC
hashdotdesign-tokens	Ready	Preview	Sep 7, 2026 7:52am UTC
petrinaut	Ready	Preview	Sep 7, 2026 7:52am UTC
petrinaut-docs	Ready	Preview	Sep 7, 2026 7:52am UTC

[cursor]

PR Summary

Medium Risk
Expands the public Select API and interaction model (multi-value, search, keyboard); regressions could affect forms app-wide, though changes are isolated to ds-components with typed props and stories.

Overview
Select gains multiple mode with array value/onChange, optional maxItems, and richer dropdown rows via MultiSelectItem (checkbox/tick/highlight variants, tones, suffixes, hover "Only" to isolate one choice). Single- and multi-select props are split at the type level so renderSelectedItem and maxItems stay correct.

A shared searchable dropdown filter filters by item text, calls onSearch, resets on close, and keeps list highlight in sync for keyboard use from the search field (SearchHighlightSync). SelectableListSearch replaces duplicated search UI in SortMenu and adds placement-aware styling so the search row stays next to the trigger when the popover flips upward; SelectableList layout and Select custom-row key handling support that.

Supporting tweaks include clear-button focus visibility, multi-select list spacing, new Ladle stories, and exporting MultiSelectItem from the package entry.

^{Reviewed by Cursor Bugbot for commit 04bb78e. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Stale Bugbot comment from a previous run.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 04bb78e. Configure here.}

[lunelson]

I'm wondering only if the value should be sorted in the same order as the options. It's possible to create different values which are logically identical but will appear different depending on the order in which they were clicked

[alex-e-leon]

I'm wondering only if the value should be sorted in the same order as the options. It's possible to create different values which are logically identical but will appear different depending on the order in which they were clicked

Its not a bad idea, and I almost went ahead and implemented it, but after thinking about it I think it's better not to have this.

In practice it's not really an issue - it won't create any issues with memoization, since in order to change the order, a user would need to unselect and re-select options which would already trigger onChange with the inbetween states and therefore break any memoization in the interim.

And in cases where the order is important the consuming developer is likely already sorting, and in practice its often not a straight alphabetical sort, so we would be double sorting in some scenarios.

But the actual reasons I decided it's better not to implement it are
a) either the selected UI would annoyingly sort for users (so when a user selected an item it could be added to the front) or the data + ui would be out of sync
b) it also prevents a consumer from knowing the order a user selected options, and in some situations the order may be important. Leaving it unsorted gives developers more control on how its used.