Skip to content

Conversation

@nicokempe
Copy link
Contributor

@nicokempe nicokempe commented Dec 21, 2025

🔍 Description

This PR separates type-only exports from runtime re-exports in the supabase-js entrypoint to prevent bundlers from emitting false-positive “imported but never used” warnings during dev builds.

No runtime behavior is changed.

What changed?

  • Converted PostgrestError and FunctionInvokeOptions to type-only exports
  • Kept runtime exports (FunctionsClient, FunctionsError, etc.) unchanged
  • Avoided mixed imports where runtime-used symbols and type-only symbols were imported together

This ensures bundlers can safely tree-shake unused exports without leaving behind unused imports.

Why was this change needed?

When running pnpm dev (Nuxt / Vite / Rollup pipeline in my case), the bundler performs dependency optimization and tree-shaking.

Because supabase-js previously imported runtime-used symbols (e.g. PostgrestClient) together with symbols that are only re-exported for typing purposes (e.g. PostgrestError), tree-shaking removed the re-exports but left the combined import intact. This resulted in warnings such as:

"PostgrestError" is imported but never used

These warnings are not runtime issues, but they create noise for users during development.

Splitting type-only exports avoids this pattern and aligns better with how bundlers handle ESM + TypeScript.

Closes #1973

📸 Screenshots/Examples

Before:

[16:26:09]  WARN  "PostgrestError" is imported from external module "file://C:/Users/accou/WorkSpace/GitHub/DashioDevs/website/node_modules/.pnpm/@supabase+postgrest-js@2.89.0/node_modules/@supabase/postgrest-js/dist/index.mjs" but never used in "node_modules/.pnpm/@supabase+supabase-js@2.89.0/node_modules/@supabase/supabase-js/dist/index.mjs".
[16:26:09]  WARN  "FunctionRegion", "FunctionsError", "FunctionsFetchError", "FunctionsHttpError" and "FunctionsRelayError" are imported from external module "file://C:/Users/accou/WorkSpace/GitHub/DashioDevs/website/node_modules/.pnpm/@supabase+functions-js@2.89.0/node_modules/@supabase/functions-js/dist/main/index.js" but never used in "node_modules/.pnpm/@supabase+supabase-js@2.89.0/node_modules/@supabase/supabase-js/dist/index.mjs".

🔄 Breaking changes

  • This PR contains no breaking changes

📋 Checklist

  • I have read the Contributing Guidelines
  • My PR title follows the conventional commit format: <type>(<scope>): <description>
  • I have run npx nx format to ensure consistent code formatting
  • I have added tests for new functionality (if applicable)
  • I have updated documentation (if applicable)

📝 Additional notes

This change is intentionally minimal and focused on improving developer experience during bundling. It does not affect runtime behavior, public APIs, or existing imports, and only refines how types are exported for downstream tooling compatibility.

@nicokempe nicokempe mentioned this pull request Dec 21, 2025
7 tasks
@nicokempe nicokempe marked this pull request as ready for review December 22, 2025 22:41
@nicokempe nicokempe requested a review from a team as a code owner December 22, 2025 22:41
@mandarini mandarini changed the title fix(#1973): split type-only exports to avoid unused import warnings fix(supabase): split type-only exports to avoid unused import warnings Dec 23, 2025
@mandarini
Copy link
Contributor

@nicokempe thank you for the PR. Can you please make sure your commit message matches the required pattern for conventional commits? You can use the commit wizard to help you, run npm run commit. Essentially, it should be type(scope): message. I updated the PR title for you.

@mandarini mandarini merged commit 30f9600 into supabase:master Dec 23, 2025
17 of 18 checks passed
@mandarini
Copy link
Contributor

@nicokempe nevermind, I merged with message from PR title

@mandarini mandarini self-assigned this Dec 23, 2025
@nicokempe
Copy link
Contributor Author

@nicokempe nevermind, I merged with message from PR title

Thank you and sorry @mandarini, I have gotten into the habit of defining the issue ID (#1973 in this case) as the scope based on the conventions of other projects that I work on so that the reason for the commit can be found quickly, but I understand why you would not want to do it that way. Thank you very much for updating.

@coveralls
Copy link

Coverage Status

coverage: 95.349% (+14.0%) from 81.37%
when pulling f8644cc on nicokempe:master
into c5f4e08 on supabase:master.

@mandarini
Copy link
Contributor

@nicokempe oh I see. Yes, we do it that way because we have some release automation around it, so that it can group fixes/feats according to the scope in the packages changelogs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

warning about imports never used

3 participants