mirror of
https://github.com/supabase/supabase.git
synced 2026-10-07 18:35:07 +03:00
* feat: add support for dropping and auto-extracting zip files in Edge Functions editor * fix: add type assertions for readonly array includes checks in zip extraction Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com> * feat: add support for PDF and image files in zip extraction - Moved wasm from ALLOWED_EXTENSIONS to ALLOWED_BINARY_EXTENSIONS - Added PDF support for document files - Added common image formats: jpg, jpeg, png, gif, svg, bmp, ico, webp - Binary files are extracted and preserved but show "Cannot Edit" message in editor Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com> * refactor: remove file extension validation from zip extraction Makes zip extraction behavior consistent with regular file drops. Now all file types are accepted in both cases, matching the permissive behavior users expect. Removed: - ALLOWED_EXTENSIONS and ALLOWED_BINARY_EXTENSIONS arrays - isAllowedExtension() and isAllowedBinaryFile() validation functions - getFileExtension() helper (no longer needed) - Extension-based rejection logic from extractZipFile() Kept: - File size validation (individual and total limits) - Hidden file filtering (.DS_Store, __MACOSX, etc.) - Binary file detection for proper content reading Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com> * fix: correct file replacement detection in addDroppedFiles Bug: The condition `updatedFiles !== files` always evaluated to true because updatedFiles is created via files.map() which always returns a new array reference, even when no files were actually modified. This caused onFilesChange to be called unnecessarily when dropping zip files that only contained files with names not matching any existing files. Fix: Track whether any existing files were actually replaced using a hasReplacedFiles flag that is set to true only when we modify files in the updatedFiles array during zip extraction. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com> * fix: add graceful error handling for zip file extraction Replaced dangerous non-null assertion operator (!) with proper error handling for entry.getData() calls. Changes: - Check entry.directory and entry.getData before extraction - Wrap getData calls in try-catch to handle extraction failures - Track failed files and include them in error reporting - Skip files that can't be extracted instead of crashing This prevents runtime errors when: - Zip entries are directories (defensive check) - Zip entries don't have getData method (corrupted/unusual entries) - File extraction fails for any reason (encoding issues, etc.) - Binary/text file reading encounters errors Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com> * refactor: improve file processing logic with enum and switch statement Replaced if-else chain with cleaner enum-based approach per PR feedback. Changes: - Added FileAction enum (CREATE_NEW, REPLACE_EXISTING, REPLACE_NEW) - Created getFileAction() helper function that returns action + index - Refactored file processing loop to use switch statement - Eliminated duplicate findIndex() calls (was calling it twice) - Reduced variable count from 2 (existingFileIndex, newFileIndex) to 1 (actionResult) Benefits: - More readable and maintainable code - Single source of truth for file lookup logic - Better type safety with discriminated union - Easier to extend with new file actions in the future Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com> * prettier * fix: add guard for undefined entry.uncompressedSize in zip extraction Prevents NaN from bypassing size validation when entry.uncompressedSize is undefined. Issue: - entry.uncompressedSize can be undefined in malformed/corrupted zips - Without guard: totalExtractedSize + undefined = NaN - NaN comparisons always return false, bypassing MAX_TOTAL_EXTRACTED_SIZE - Security risk: allows extraction of files with unknown sizes Fix: - Check if uncompressedSize is undefined or NaN before any arithmetic - Skip files with unknown sizes and add to oversizedFiles array - Provide descriptive error message: "unknown size - metadata unavailable" - Ensures size validation always runs safely Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com> * Refactor to streamline handling of regular and zip files in FileExplorerAndEditor * Address rabbit feedback * Nit --------- Co-authored-by: Claude Sonnet 4.5 <noreply@anthropic.com> Co-authored-by: Joshen Lim <joshenlimek@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
const ComponentA = ({ sampleProp }: ComponentAProps) => {
return <div>ComponentA: {sampleProp}</div>
}
export default ComponentA