mirror of
https://github.com/supabase/supabase.git
synced 2026-10-18 15:49:09 +03:00
089133cc2c
| # | Branch | Base | | - | ------ | ---- | | 1 | `feat/storage-versioning-private-alpha` — merged | `master` | | 2 | `feat/storage-versioning/002-bucket-form-fields` ◀ | `master` | | 3 | `feat/storage-versioning/003-bucket-modals` | 2 | | 4 | `feat/storage-versioning/004-object-versions-data` | 3 | | 5 | `feat/storage-versioning/005-file-preview-versions` | 4 | | 6 | `feat/storage-versioning/006-billing-storage-retention` | 5 | | 7 | `feat/storage-versioning/007-archived-objects-data` | 6 | | 8 | `feat/storage-versioning/008-archived-rows` | 7 | | 9 | `feat/storage-versioning/009-archived-preview-pane` | 8 | | 10 | `feat/storage-versioning/010-replace-file` | 9 | ## [2/10] Storage object versioning: bucket form fields The object versioning + lifecycle policy form section for the create and edit bucket modals. Mounted onto the ui in PR 3 #49205 - `BucketVersioningFields` — the versioning switch and the suspension / public-bucket / retention-tightening warnings - `LifecyclePolicySection` — the retention window and version cap inputs - `ExpirationModeToggle` — how the two conditions combine (and / or) - `BucketVersioningFields.schema.ts` — zod fields the parent modals spread into their own schema, plus `superRefineBucketVersioning` - `BucketVersioningFields.utils.ts` — retention-tightening detection - `StorageVersioning.constants.ts` — versioning state and expiration mode types, the prefill defaults, and `getBucketVersioningState` Note: a single s3 lifecycle policy expects both `version_expiry_days` and `max_noncurrent_versions` and always evaluate the two fields within the same policy with an AND logic. To enable both AND and OR/EITHER logic, we save two distinct s3 policies so we can enforce the OR logic. See demos and how to reproduce in #49205 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Summary * **New Features** * Eligible projects with the preview enabled can configure object versioning for storage buckets, including version expiration, retained-version limits, and “and/or” lifecycle conditions. * Settings default to 30 days and 10 retained versions, with validation for retention values and requirements for setting a version limit. * Notices highlight public buckets, missing lifecycle conditions, suspending existing versioning, and changes that tighten retention limits. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com> Co-authored-by: Ivan Vasilov <vasilov.ivan@gmail.com>
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 — use a named export, not a default export
export const ComponentA = ({ sampleProp }: ComponentAProps) => {
return <div>ComponentA: {sampleProp}</div>
}