mirror of
https://github.com/supabase/supabase.git
synced 2026-10-07 02:15:05 +03:00
Utkarash Kumar Singh
a5b820d51b
## What Studio + docs support for two **non-blocking** upgrade-eligibility warnings for the PG 15.18 / 17.10 release: - **`ltree_reindex_required`** — ltree indexes on a multibyte / non-libc database must be `REINDEX`ed after upgrade. - **`operator_estimator_gate`** — operators referencing a non-built-in selectivity estimator (CVE-2026-2004) can't be recreated by a non-superuser. ## Changes - `UpgradeWarnings.tsx` — title/description/link for both types; unrecognized warning types are skipped rather than rendering an empty admonition. - `apps/docs/.../platform/upgrading.mdx` — two upgrade-guide sections (with detection + remediation SQL) that the warnings link to. - `api-types` — the two types added to `ProjectUpgradeEligibilityResponse.warnings`. ## Server side Detection/emission lives in the platform repo: **supabase/platform#34161**. Both warnings are version-gated there (only fire when upgrading to ≥ 15.16 / 17.8). Refs: PSQL-1247 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Upgrade warnings now support additional warning types, with type-specific titles, descriptions, and optional “Read upgrade notes” links. * The project upgrade eligibility response now returns these additional warning types. * **Bug Fixes** * Upgrade warnings are rendered consistently for all warning entries (no special-casing). * **Documentation** * Added Postgres `ltree` upgrade warnings, including detection queries and `REINDEX INDEX CONCURRENTLY` remediation guidance. * Added operator selectivity estimator warnings, including superuser requirements and how to detect affected operators. * **Chores** * Updated spelling lint exceptions for common terms. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
Writing components
Where to create your components
- For components that declare the general structure and layout of a page:
/components/layouts/xxx
- For components that are tightly coupled to a specific interface:
/components/interfaces/xxx
- For components that are meant to be reusable across multiple pages:
/components/ui/xxx
- Note: We're gradually moving files out of the
to-be-cleanedfolder into the respective folders as we refactor
Component structure
- If a component has constants and utility methods that are tightly coupled to itself, keep them close to the component and enclose them in a folder with an
index.tsxas an entry point - Otherwise it can just be a file on its own
- For example:
-
components/ui - SampleComponentA - SampleComponentA.tsx - SampleComponentA.constants.ts - SampleComponentA.utils.ts - SampleComponentA.types.ts - index.ts - SampleComponentB.tsx
-
Template for building components
// Declare the prop types of your component
interface ComponentAProps {
sampleProp: string
}
// Name your component accordingly
const ComponentA = ({ sampleProp }: ComponentAProps) => {
return <div>ComponentA: {sampleProp}</div>
}
export default ComponentA