feat(types): export more PostgrestResponse, PostgrestBuilder and PostgrestClient types from postgrest-js

[maximilian-hammerl]

What kind of change does this PR introduce?

Export more PostgrestResponse, PostgrestBuilder and PostgrestClient types from postgrest-js

As the return type of, among others, the filter methods of the PostgrestFilterBuilder class, the types are significant if one wants to type the response when calling the filter methods.

What is the current behavior?

Currently, one has to have postgrest-js as a dependency just for the PostgrestResponse, PostgrestBuilder and PostgrestClient types.

[coveralls]

Pull Request Test Coverage Report for Build 12825599938

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 67.805%

---

Totals
Change from base Build 12823066490:	0.0%
Covered Lines:	101
Relevant Lines:	130

---

💛 - Coveralls

[maximilian-hammerl]

Hi @avallete, anything missing for this PR to get approved and merged? Anything I can help with?

[avallete]

I'm not too sure we want to expose these types for external use.

Users might feel encouraged to build on top of them when using supabase-js and expect their behavior to remain stable. However, since these types are an internal implementation detail, we could break or remove them entirely in the future. This would force us to make major releases more frequently, as fixing behaviors could introduce breaking changes in the types.

@soedirgo, what do you think?

If we’re okay with more frequent breaking changes/major releases, then I guess it’s fine to go ahead.

Alternatively, we can continue require keeping postgres-js in the dev dependencies (as it is now) if users want to rely on its types for building code. That might be the safer approach.

[soedirgo]

Yeah, these types are internal implementation detail as far as supabase-js is concerned, so we don't want users to be dependent on their stability.

For your use case, you can consider using TypeScript's ReturnType instead - I don't foresee that causing issues if we change the return types of filter methods etc.