Tree shaking

[lawrencecchen]

Feature request

Tree-shaking is currently not possible with the supabase-js library because SupabaseClient is implemented using classes. Neither Webpack or Rollup supports tree-shaking class methods.

Is your feature request related to a problem? Please describe.

Supabase bundle size is quite small compared to others (firebase, amplify), but it will only increase as more features are added. Projects that do not use all the features that Supabase provides will regardless pay the cost. Firebase has realized this with their new Modular Javascript SDK.

Describe the solution you'd like

Instead of initializing a single Supabase client, here's a modular API proposal:

// initSupabase.js
const supabaseClient = createClient(supabaseUrl, supabaseKey);
// Does not automatically instantiate RealtimeClient, PostgrestClient, etc.
// Features can be opted in as such:
export const db = getPostgrest(supabaseClient);
export const realtime = getRealtime(supabaseClient);
export const auth = getAuth(supabaseClient);
export const storage = getStorage(supabaseClient);

// some-random-component.js
import { db, realtime } from './initSupabase';

const { data, error } = await db
  .from('cities')
  .select()

const mySubscription = realtime
  .from('*')
  .on('*', payload => {
    console.log('Change received!', payload)
  })
  .subscribe()

While this won't eliminate every piece of unused code, it's a start to enabling opt-in for specific features.

Caveats

• Will break the current stable API, but can be remedied w/ codemods.
• Not sure if SupabaseAuthClient can be separated as all other modules rely on that

If this is something you guys think is worth pursuing, I'd be happy to start working on a PR!

[maxcodefaster]

For the meantime, is there a supabase package available without realtime.js, as it increase bundle size significantly?

[soedirgo]

@maxcodefaster you can use the client library for each components independently, but you need all for supabase-js.

What's common.js? There's no significant bloat in realtime-js as far as I'm aware.

[maxcodefaster]

nvm. i got an error on angular cli stating that realtime-js relies on common.js and thus increases bundle size. i forked supabase-js and remove realtime-js references, if someone is interested:

https://www.npmjs.com/package/supabase-js-without-realtime-js

[micahjon]

... i forked supabase-js and remove realtime-js references, if someone is interested:

https://www.npmjs.com/package/supabase-js-without-realtime-js

@maxcodefaster , is your fork still up-to-date? supabase-js is currently the largest dependency of my app and I currently only use auth. Thanks!

[sannajammeh]

+1 on this. Also fixes the issue of "realtime" being imported in Next.js' Edge runtime.

[madebyfabian]

I am wondering, is the new supabase v2 RC solving tree shaking? I am seeing that the dist is actually a tiny bit larger than in v1.

v2 dist

v1 dist

I am seeing the ability to define certain settings for createClient

const options = {
  db: {
    schema: 'public',
  },
  auth: {
    autoRefreshToken: true,
    persistSession: true,
    detectSessionInUrl: true,
  },
  global: {
    headers: { 'x-my-custom-header': 'my-app-name' },
  },
}
const supabase = createClient(
  'https://xyzcompany.supabase.co',
  'public-anon-key',
  options
)

I am using only the database and storage function of supabase. Wouldn't it be great to allow something like:

const options = {
  db: true,
  auth: false,
  realtime: false,
}
const supabase = createClient(
  'https://xyzcompany.supabase.co',
  'public-anon-key',
  options
)

or like https://github.com/storyblok/storyblok-js#initialization does it

import { databaseFeature, storageFeature } from '@supabase/supabase-js/features'
const options = {
  useOnlyFeatures: [databaseFeature, storageFeature]
}
const supabase = createClient(
  'https://xyzcompany.supabase.co',
  'public-anon-key',
  options
)

[soedirgo]

We weren't considering tree-shaking in v2, but might in v3. That said there seems to still be some low hanging fruits here - realtime-js seems to have doubled in size 🤔

[binyamin]

We weren't considering tree-shaking in v2

@soedirgo May I ask why? Supabase-js is a whopper. I'd much rather download the library on my server instead of making every single user download it in the browser.

[soedirgo]

There are more pressing issues right now, esp. wrt functionality - once the client libs are stable enough we'll look into how to refactor them to support tree-shaking.

[Andrewjeska]

+1, I'm using the supabase client solely for auth for a nextjs app. Would be nice to isolate the bits I'm not using :)

[abhishiv]

@soedirgo am I right to say that the bundle size is huge since of the npm websocket package(16k) which cause the entire size to be 26kb currently.

Since all browsers already support websocket, that should be easy win and fix and provide a browser build right? I would be happy to make a PR if you would consider it!

[soedirgo]

Hmm, the websocket package isn't that big actually (1.1KB), but yeah that'd help trim it down. Though a bigger win would be from omitting cross-fetch (2.8KB) on environments that don't need it.

[sannajammeh]

Hmm, the websocket package isn't that big actually (1.1KB), but yeah that'd help trim it down. Though a bigger win would be from omitting cross-fetch (2.8KB) on environments that don't need it.

Agreed. Most frameworks already polyfill, its supported in all major browsers and even Node JS at this point. Most React libraries already target ES6 only and tell users to polyfill. The best solution would be adding some docs about polyfilling and omitting it altogether. There is no reason for a library to provide its own polyfill imho.

[mikestopcontinues]

Even better if you could install each module separately.

I'm trying to bundle a docker image, but realtime-js depends on bufferutils and utf-8-validate, both of which must be built from source during install. I don't need realtime-js, and I really don't want to install python, make, etc, just to tree-shake it all away later. I have to generate many permutations of my container per deploy, so the build-time really adds up (in dev time and CI/CD cost).

This doesn't necessarily mean everyone needs to install multiple packages. I'm sure a lot of people want just the one. But it wouldn't surprise me if others are hitting this docker issue.

[abhishiv]

Hey @mikestopcontinues, if all you use is the REST API, maybe using https://github.com/hugomrdias/postgrest-url with fetch would work for your use case!

Just mentioning it since not sure what's the timeline for v3.

[mikestopcontinues]

Thanks @abhishiv, I ended up just creating a fork in the meantime.

BTW, @soedirgo, websocket isn't big, but it does cause the issue I described above. The package hard-requires bufferutil and utf-8-validate, while ws has better handling around those packages. It's also a better-maintained package overall, and created by the same guy who made bufferutil and utf-8-validate.

As it stands, websocket prevents supabase-js from easily being installed in slim/alpine arm64 docker images without jumping through hoops. It would make tree-shaking a perfectly viable solution, since it would circumvent needing to build binaries. Any chance of switching?

[remorses]

Currently Supabase takes about 300ms to be required in a AWS lambda function

Being able to only require the part of Supabase could significantly decrease cold starts for many projects:

require profile here

[soedirgo]

Thanks all! Some updates on reducing the bundle size:

• we're in the process of replacing cross-fetch with just node-fetch, which should shave around 3kB
• we're planning to remove node-fetch altogether in v3
• we're planning to replace websocket with ws, but we need to PoC this first - PRs welcome!

There's no timeline for tackling treeshaking at the moment, but we're open to proposals on how this could be done - ideally we don't have to sacrifice DX for this.

[remorses]

For fetch you can use native-fetch to use the Nodejs 18 or browser native implementation when possible: https://github.com/achingbrain/native-fetch

[binyamin]

@soedirgo

ideally we don't have to sacrifice DX for this.

DX is nice, but apps are for users, not developers. Bundle size affects the user, so that should take a higher priority. DX is an extra. The deliverables are the important part.

[BeeeQueue]

Here's a nice website for checking how large each part of supabase-js is when it's bundled in an application

Just click Build and then expand the Analysis collapsible: https://bundlejs.com/?q=%40supabase%2Fsupabase-js&treeshake=%5B%7BcreateClient%7D%5D&config=%7B%22analysis%22%3A%22sunburst%22%7D

These are the current stats:

name       gzip/size   %

gotrue     23kb/107kb  39%
realtime   14kb/ 55kb  20%
postgrest  10kb/ 41kb  15%
storage     7kb/ 33kb  12%
supabase    5kb/ 14kb  5%
functions   2kb/  6kb  2%

cross-fetch 4kb/ 15kb  5%

[enyo]

@binyamin DX is nice, but apps are for users, not developers. Bundle size affects the user, so that should take a higher priority. DX is an extra. The deliverables are the important part.

I couldn't agree more. It's especially frustrating when you need to handle authentication. We have auth on the landing page, which means that the whole supabase SDK needs to load the first time the user visits, just to handle auth.

I really wished the supabase team would take this issue seriously and see it as a priority.

@soedirgo you were asking for proposals, but I think that the original proposal is completely fine. The functions could be shorter but in essence:

import { storage } from 'supabase';

storage(mySupabase).etc

another way:

mySupabase.with(storage).etc

it could also "enhance" the supabase instance:

let enhancedSupabase = mySupabase.with(storage, auth)

enhancedSupabase.etc

All proposals seem fine to me but other frameworks might already solve this in a better way.

[KTibow]

If you just use @supabase/postgrest-js, you get 12% over the wire size.