Dropping a Node version lands in a minor release, and that is the policy

One install, six packages behind it

The repository is a monorepo and the page describes it as the complete suite of the Supabase JavaScript SDK. Six packages sit under packages/core, and only one of them is what most projects install:

npm install @supabase/supabase-js

The other five are the pieces that package is assembled from: @supabase/auth-js for authentication, @supabase/postgrest-js for database operations, @supabase/realtime-js for real-time subscriptions, @supabase/storage-js for file storage, and @supabase/functions-js for Edge Functions invocation. That split is the useful part for anyone hitting an unexpected behaviour, because a realtime problem and an auth problem are debugged in different repositories' worth of code.

Support is defined by release schedules, not by versions

The support policy is the longest section of the page and it is organised by runtime. For Node.js, only versions in Active LTS or Maintenance status are supported, following the official Node release schedule. For Deno, the rule is versions receiving active development and security updates, taken from the stable and lts release channels. Browsers are supported when they provide a native fetch API, and realtime additionally requires a native WebSocket API. Bun, React Native and Cloudflare Workers are each supported on current stable versions, with React Native assumed to use the fetch polyfills the framework provides. The line worth reading twice is the consequence: when a runtime reaches end of life, support is dropped in a minor release, and the page states plainly that this won't be considered a breaking change.

Node 18 and Node 20 have exact cut-off versions

Two deprecation notices give the numbers directly. Node.js 18 reached end of life on April 30, 2025, support was dropped in version 2.79.0, and 2.78.0 is named as the last version that supported it. Node.js 20 reached end of life on April 30, 2026, support was dropped in version 2.110.0, and 2.109.0 is the last version that supported it. So the current line has already moved past both, and the same will happen to whichever runtime you are on when its own end of life date arrives. Because the drop is a minor release rather than a major one, a version range in your manifest will silently stop being supported, and nothing in a dependency bump will tell you that the floor moved. Pinning an exact version is the only way this page's policy stays on your side.

The root package is private and versioned 0.0.0

The root package.json is not the published package. It is named @supabase-js/source, marked private, and carries version 0.0.0, so nothing you install comes from the repository root. Publishing is driven by three scripts instead:

pnpm exec tsx scripts/release-canary.ts
pnpm exec tsx scripts/release-beta.ts
pnpm exec tsx scripts/release-stable.ts

That split shows up in the tags. Recent releases are v2.119.0-canary.4 published on 2026-10-28, v2.119.0-canary.3 on 2026-10-27, and v2.119.0-canary.2 on 2026-10-22, and the default branch, master, had its last push on 2026-11-02. The repository also pins pnpm at 11.1.2 through the packageManager field, which matters if your CI resolves the package manager itself.

Generated types are diffed in CI rather than built at install

Two sets of generated types are guarded by scripts that fail when they drift. `codegen` runs scripts/sync-common-types.js, and `codegen:check` runs the same script and then diffs packages/core/supabase-js/src/lib/rest/types/common, printing whether the generated types are in sync and telling you to run pnpm codegen otherwise. A parallel pair exists for PostgREST: codegen:postgrest runs scripts/generate-postgrest-types.js, and its check variant compares packages/core/postgrest-js/test/types.generated.ts. The check script separates two failures on purpose, telling you that if type generation itself failed, re-running codegen will not help. There is also a preinstall hook, node scripts/preinstall.js, and a prepare hook that runs husky, so a local clone installs differently from a published package.

Contribution runs through nx, commitlint and husky

The root package.json defines a `commit` script that runs commitizen (`cz`) and a `prepare` script that runs husky. The commit step goes through commitizen configured in package.json to use @commitlint/cz-commitlint, and @commitlint/config-conventional is among the devDependencies.

Two caveats the page admits up front

The important notes are short and both matter before you commit to this client. First, features marked as experimental may be removed or changed without notice, so anything on an experimental label carries no compatibility promise at all. Second, if you see UNUSED_EXTERNAL_IMPORT warnings from Vite or Nuxt, the page points you at the supabase-js README and says these are false positives, which is the sort of note that saves an afternoon of chasing a bundler warning that has no effect on your output. Neither note is developed further on this page, so if either applies to your build, the per package README and the linked guides are where the detail has to come from.

Testing and documentation are organised per package

Each of the six packages has its own directory under packages/core, and the root carries CONTRIBUTING.md and a docs/ directory. The rest of the tree shows how the repository is wired: nx.json and project.json drive the task graph, eslint.config.mjs and .prettierrc handle linting, typedoc.base.mjs generates API docs, CODEOWNERS names reviewers, and .nvmrc plus .husky/ pin the local toolchain and commit hooks. Documentation lives at supabase.com as Guides and Reference Docs.

Editorial conclusion

supabase-js fits a team that wants one client for PostgREST queries, realtime subscriptions, storage and Edge Functions, and that pins versions deliberately, because the support policy drops a runtime in a minor release and says so. It does not fit a team on an end of life runtime that cannot upgrade soon, since Node 18 support was dropped in 2.79.0 and Node 20 support in 2.110.0. Before you adopt it, decide whether you are installing the combined SDK or one of the five focused packages, pin a non canary version, and remember that experimental features can be removed or changed without notice.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. supabase/supabase-js on GitHub