Mark arrays accepted by filter builder methods readonly.
What is the current behavior?
Currently filter builder methods accept non-readonly arrays. This is fine, but forces casting readonly arrays to non-readonly versions even though Supabase methods do not mutate the passed-in arrays.
See:
const ALLOWED_STATUSES = ["ACCEPTED", "PENDING"] as const;
supabase.from("tasks")
.select()
.eq("status", ALLOWED_STATUSES) // tsc error: Argument of type 'readonly (..)[]' is not assignable to parameter of type '(..)[]'.
What is the new behavior?
All filter builders accepting arrays will accept the readonly version. Since this only changes function parameter signature and none of the returned values, it should be a non-breaking change.
Additional context
Quite many libraries (and notably, Typescript's own as const) use readonly arrays, so this makes working with them a bit easier and less-casting-needed.
What kind of change does this PR introduce?
Mark arrays accepted by filter builder methods readonly.
What is the current behavior?
Currently filter builder methods accept non-readonly arrays. This is fine, but forces casting readonly arrays to non-readonly versions even though Supabase methods do not mutate the passed-in arrays.
See:
What is the new behavior?
All filter builders accepting arrays will accept the readonly version. Since this only changes function parameter signature and none of the returned values, it should be a non-breaking change.
Additional context
Quite many libraries (and notably, Typescript's own
as const
) use readonly arrays, so this makes working with them a bit easier and less-casting-needed.