This PR migrates the whole monorepo to use Tailwind v4:
- Removed `@tailwindcss/container-queries` plugin since it's included by
default in v4,
- Bump all instances of Tailwind to v4. Made minimal changes to the
shared config to remove non-supported features (`alpha` mentions),
- Migrate all apps to be compatible with v4 configs,
- Fix the `typography.css` import in 3 apps,
- Add missing rules which were included by default in v3,
- Run `pnpm dlx @tailwindcss/upgrade` on all apps, which renames a lot
of classes
- Rename all misnamed classes according to
https://tailwindcss.com/docs/upgrade-guide#renamed-utilities in all
apps.
---------
Co-authored-by: Jordi Enric <jordi.err@gmail.com>
This PR preps the monorepo for a migration to Tailwind v4:
- Bump all Tailwind dependencies and libraries to the latest possible
version, while still compatible with Tailwind 3.
- Cleans up obsolete Tailwind 3 specific options and configs.
- Cleans up unused CSS files and fixes the CSS imports.
- Migrates all `important` uses in `@apply` lines to using the `!`
prefix.
- Move `typography.css` to the `config` package and import it from the
apps.
- Migrated all occurrences of `flex-grow`, `flex-shrink`,
`overflow-clip` and `overflow-ellipsis` since they're deprecated and
will be removed in Tailwind 4.
- Make the default theme object typesafe in the `ui` package.
- Migrate all `bg-opacity`, `border-opacity`, `ring-opacity` and
`divider-opacity` to the new format where they're declared as part of
the property color.
- Bump and unify all imports of `postcss` dependency.
Currently when a user clicks the **Install integration** button on an
OAuth integration like Grafana, they are redirected to the partner
website in the same tab in which they clicked the button. This makes
them lose context in the Supabase Studio. This PR changes the behaviour
such that the partner website will be opened in a new tab.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* OAuth integration installation now opens the redirect URL in a new
browser tab instead of redirecting the current window, allowing users to
remain in the application while completing the integration process.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Problem
We used to have a `_Shadcn_` suffix for all the shadcn form components
because we also had `formik` form components.
This is not needed anymore.
## Solution
- Remove the suffix
- Update all usages
This PR integrates with the new marketplace db to allow Grafana (and
other partners) OAuth apps to install from the integrations page. A demo
of this working locally is available here:
https://supabase.slack.com/archives/C01GN60J0BS/p1775551752479709. End
to end flow is documented here:
https://www.notion.so/supabase/Grafana-Integration-Flow-33a5004b775f80eeaf91c098beb8071f.
TODO:
- [ ] Make sure `NEXT_PUBLIC_MARKETPLACE_API_URL` variable is set to the
new marketplace db.
- [x] Test with the `marketplaceIntegrations` enabled and disabled in
staging once https://github.com/supabase/platform/pull/31298 is merged
and available in staging.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Add OAuth "Install integration" button that detects installed
integrations and supports GET/POST install flows
* Marketplace listings now include install links, installation method,
partner info, and listing assets/logos
* **Infrastructure**
* Allow marketplace API origin for images and content in security and
image config
* Centralize marketplace types and switch marketplace data source for
more reliable listings
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
## Problem
We'd like to update react to `19` but many of our dependencies don't
support it.
## Solution
Update those dependencies. This PR focuses on `react-hook-form`
## How to test
Play with some forms, especially those that use arrays of values
(database/enumerated types for instance) and the highly dynamic ones
(auth providers for instance)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Summary by CodeRabbit
* **Chores**
* Bumped the form-handling library version across apps and packages for
improved compatibility and stability.
* **Refactor**
* Improved component form typings and generics in the studio to increase
type safety and reduce potential runtime issues.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Context
Part of marketplace integrations, this moves the last integration over
to the new integrations UI
Just a heads up though that the code changes imo are quite messy - am
trying to figure out how to shift a lot of the integration logic (e.g
installing, installation progress tracking, etc) into a code
configuration within `Integrations.constants.ts` so pardon the
mid-transition state. I reckon we'll be able to clean up things once
requirements are bit more clearer. (Refer to "Moving forward" section
below for details)
## Changes involved
- Much of the details on the Stripe Sync Engine page will now live in
the Installation panel
<img width="1143" height="512" alt="image"
src="https://github.com/user-attachments/assets/cb23e49d-cc4e-4ad6-8a47-0bc3fe81ede7"
/>
<img width="656" height="955" alt="image"
src="https://github.com/user-attachments/assets/ff0e33c5-52ab-480f-b941-ebf3fd0708c5"
/>
- Code wise, `useStripeSyncStatus` will retrieve `ref` and
`connectionString` itself, don't need to pass in as parameters
## To test
- [ ] Verify that you can install + uninstall Stripe Sync Engine with
the flag off
- [ ] Verify that you can install + uninstall Stripe Sync Engine with
the flag on
## Moving forward
Couple of notes + open questions at the top of my head
- We'll need to do away with integration-specific overview UI (e.g
Queues, Data API, Webhooks, Wrappers, Stripe Sync Engine)
- Everything needs to be defined in code, so `IntegrationDefinition`
within `Integrations.constants.ts` is also a bit fluid at the moment as
we figure out what properties we need / don't need
- We'll need to figure out a way to do the following from a code config
POV, keeping in mind that integrations will be fetched remotely from a
DB
- How to trigger the installation of the integration (e.g from a set of
commands? SQL?)
- How to track the progress of the installation (e.g We can do long
polling but on what data?)
- How to uninstall the integration (if applicable, e.g Stripe Sync
Engine supports this)
- How all this this can work for self-hosted/CLI
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* New modular integration install experience: interactive install sheet
with form inputs, installation overview (Extensions & SQL), advanced
per-extension schema settings, and dedicated installation settings.
* New Stripe Sync Engine overview and action controls for
install/upgrade/uninstall flows.
* **Bug Fixes & Improvements**
* Improved installation status handling, long-polling/status checks,
progress/error reporting and telemetry; more robust install/uninstall
flows and error recovery.
* **Tests**
* Updated install-sheet tests to better simulate form submission.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
Co-authored-by: Alaister Young <alaister@users.noreply.github.com>
