fix(storage): keep sortBy defaults when list() is given a partial sortBy

[i-anubhav-anand]

🔍 Description

What changed?

StorageFileApi.list() shallow-spread its defaults into the request body, so a partial sortBy dropped the sibling default. This deep-merges sortBy so a partial override keeps the default for whichever key you don't set.

Why was this change needed?

The case that actually fails today is order-only: list('folder', { sortBy: { order: 'desc' } }). On master this sends a sortBy with no column, and the Storage server requires column, so it returns a 400. With the deep merge, column falls back to 'name' and the request succeeds. (The symmetric column-only case likewise keeps the default order: 'asc'.)

📸 Examples / Proof

test/list-sortby-defaults.test.ts (Docker-free, custom-fetch capture). On master the order-only and column-only cases fail; with this change all pass:

• { sortBy: { order: 'desc' } } → { column: 'name', order: 'desc' } (was { order: 'desc' } → server 400)
• { sortBy: { column: 'updated_at' } } → { column: 'updated_at', order: 'asc' }
• no options → { column: 'name', order: 'asc' }

🔄 Breaking changes

• This PR contains no breaking changes

📋 Checklist

• I have read the Contributing Guidelines
• My PR title follows conventional commits: fix(storage): ...
• I have run pnpm nx format
• I have added tests
• Documentation (not needed)

📝 Additional notes

Rebased on master. pnpm nx build storage-js passes; the full storage integration suite (Docker) runs in CI.

[pkg-pr-new]

Open in StackBlitz

@supabase/auth-js

npm i https://pkg.pr.new/@supabase/auth-js@2454

@supabase/functions-js

npm i https://pkg.pr.new/@supabase/functions-js@2454

@supabase/postgrest-js

npm i https://pkg.pr.new/@supabase/postgrest-js@2454

@supabase/realtime-js

npm i https://pkg.pr.new/@supabase/realtime-js@2454

@supabase/storage-js

npm i https://pkg.pr.new/@supabase/storage-js@2454

@supabase/supabase-js

npm i https://pkg.pr.new/@supabase/supabase-js@2454

commit: bf8a2da

[mandarini]

Hi @i-anubhav-anand, thank you so much for contributing to Supabase!

Nice catch on the shallow spread dropping the nested sortBy default, and thank you for the Docker-free test that captures the request body directly. That makes it really easy to reason about.

One thing worth knowing: for the exact case in the description (sortBy: { column: 'updated_at' }), the storage server already defaults order to 'asc' when it is missing, so the result ordering is actually the same with or without this change for that example. Where your fix genuinely matters is the symmetric case: list('folder', { sortBy: { order: 'desc' } }). On master that sends sortBy with no column, and the server requires column, so it comes back as a 400. With your deep merge, column falls back to 'name' and the request succeeds. That is the real bug this fixes.

Could you add a test for that order-only case? It is the scenario that actually fails today, and it would make the value of the change obvious. It would also be great to lead the description with it.

Also, can you please rebase with master to fix your CI?

Thank you again for taking the time on this!!

[i-anubhav-anand]

Thanks for the careful review, @mandarini — and great catch on the server-side default. You're right that the order-only case ({ sortBy: { order: 'desc' } }) is the one that actually 400s on master, since column gets dropped and the server requires it. I've:

• Added a test for the order-only case — it fails on master (sends sortBy without column) and passes with the deep merge,
• Led the description with that scenario, and
• Rebased on master to fix CI.

Thanks again for taking the time! 🙏