## What kind of change does this PR introduce?
Bug fix / design-system alignment for the legacy `Button` from `ui`.
## What is the current behavior?
Omitting `variant` on the legacy `Button` falls back to brand-green
`primary`. That makes accidental greens easy, and it is hard to spot the
real main action on busy pages.
## What is the new behavior?
- Legacy `Button` now defaults to neutral `default`
- Intentional primary CTAs (create, save, submit, marketing CTAs, and
matching `ButtonTooltip` usages) now set `variant="primary"` so their
appearance is unchanged
- Neutral actions that previously relied on the old fallback (cancel,
close, back, dashboard nav, and similar) become grey/white
- Design-system docs updated; regression tests cover the new default
`Button_Shadcn_` is unchanged. It already uses its own CVA default.
This is PR 1 of 2 in a stack. PR 2 drops now-redundant
`variant="default"` props.
## To test
Studio (http://localhost:8082):
- `/sign-in`: Sign in stays green
- Open a project → Database → Tables: New table stays green
- Auth → Users → Invite: Invite user stays green; Cancel / dismiss
controls stay neutral
- Project Settings → General: edit a field so Cancel and Save appear.
Cancel is neutral, Save is green
Design system (http://localhost:3003):
- Components → Button: default demo is neutral; primary demo is green;
featured preview is the default variant
Marketing (optional):
- www header: Start your project stays green; logged-in Dashboard is
neutral
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **Style**
- Buttons now default to a neutral style, while primary actions across
Studio, documentation, marketing pages, forms, dialogs, and error states
use prominent primary styling.
- Updated button examples and previews clarify the distinction between
default and primary variants.
- Event registration now includes a directional arrow icon.
- **Tests**
- Added coverage confirming default button styling and explicit primary
styling behave as expected.
- Updated related test fixtures to use primary styling where
appropriate.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
This PR removes all `paths` in `tsconfig.json` for all apps and
packages. They were added previosly because some of the components had a
`_Shadcn` suffix because of an ongoing migration. How that the migration
is done, the paths can be removed.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Refactor**
* Standardized shared UI component, utility, and icon imports across
design-system examples and application screens.
* Simplified shared component access and project configuration.
* Added shared access to anchor-link helpers and animation styles.
* **Compatibility**
* Updated component exports and imports without changing existing
behavior.
* No changes to user-facing workflows, screens, or functionality.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Problem
Our `<Button>` component breaks the default `button` contract by
redefining the `type` prop to set its variant (`primary`, `default`,
etc) instead of the button type (`submit`, `button`, etc).
This is confusing and forces to write more code when using it with
shadcn components that expect/inject the standard button props.
## Solution
- rename the `type` prop to `variant`
- rename the `htmlType` prop to `type`
- propagate the changes where necessary
- format code
## How to test
As this is just prop renaming, if it builds it's ok
---------
Co-authored-by: Ivan Vasilov <vasilov.ivan@gmail.com>
## Problem
The `_Shadcn_` suffix isn't needed anymore on label component
## Solution
Remove it. No other changes
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Refactor**
* Standardized Label usage across the codebase by removing the legacy
alias and using the direct Label export from the UI package
consistently.
* **Documentation**
* Updated component examples and docs to use the standardized Label
component in usage snippets and demos.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/45986)
<!-- review_stack_entry_end -->
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.
YES
## What kind of change does this PR introduce?
Bug fix
## What is the current behavior?
On the [AI Builders](https://supabase.com/solutions/ai-builders) page
(and any other surface using the Talk to Partnerships form), submitting
on mobile rendered a blank square instead of the submission
confirmation. Linear:
[DEBR-279](https://linear.app/supabase/issue/DEBR-279/mobile-partner-form-submit-state-renders-blank-panel).
## What is the new behavior?
The success state in `TalkToPartnershipTeamForm` now drops
`min-w-[300px]` (which overflowed narrow mobile viewports), removes the
redundant `opacity-0`/`transition-opacity` pair that occasionally left
the panel stuck at opacity 0 on iOS Safari, and removes the invalid
`scale-1` class. The parent panel is now `flex flex-col` so the success
message can use `flex-1` to center properly within the `min-h-[200px]`
panel.
## Additional context
The `animate-fade-in` keyframe already uses `both` fill-mode, so it
handles the initial-to-final opacity transition without needing the
extra `opacity-0` class.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Style**
* Updated success-state container layout and styling with improved flex
sizing and spacing behavior.
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/45836)
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Danny White
