mirror of
https://github.com/supabase/supabase.git
synced 2026-10-05 01:15:03 +03:00
e66d8eb094
<!-- ccr-slack-attribution --> _Requested by **Ivan Vasilov** · [Slack thread](https://supabase.slack.com/archives/C063LNYJJKS/p1787058646458219?thread_ts=1787058646.458219&cid=C063LNYJJKS)_ **Before:** the root `package.json` pins the Supabase CLI at `supabase: ^2.76.10`, and `pnpm-lock.yaml` resolves it to `2.76.14`. **After:** it pins `supabase: ^2.114.0`. This bumps the Supabase CLI that `pnpm run e2e:setup:cli` and `pnpm run setup:cli` shell out to, so local dev and the E2E workflows boot the local stack with a CLI from this month instead of one from ~38 minor releases ago. **How:** a one-line version change to the `supabase` devDependency in the root `package.json`. Nothing else in the repo changes — no workflow, config, or test changes. ### ⚠️ This PR is incomplete: `pnpm-lock.yaml` still needs regenerating `pnpm-lock.yaml` is **not** updated in this PR, so `pnpm install --frozen-lockfile` will fail until someone runs: ```bash pnpm install --lockfile-only ``` and pushes the result to this branch. The lockfile could not be regenerated in the environment this PR was authored in: pnpm re-resolves `apps/studio`'s `"@std/path": "npm:@jsr/std__path@^1.0.8"` on every install, and `npm.jsr.io` is not reachable from there (`ERR_PNPM_FETCH_403`). Treat this PR as needing one extra commit before it can go green. ### Why `^2.114.0` and not `^2.115.0` `2.115.0` is the current `latest` on npm, but it was published only hours ago, and `pnpm-workspace.yaml` sets `minimumReleaseAge: 4320` (3 days) with `supabase` not in `minimumReleaseAgeExclude`. Pinning `2.115.0` today would fail the repo's own supply-chain check. `2.114.0` (2026-08-12) is the newest release that satisfies that policy. ## I have read the [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) file. YES ## What kind of change does this PR introduce? Dependency bump. **Speculative** — this is an experiment, not a confirmed fix. ## What is the current behavior? The `Selfhosted Studio E2E Tests` workflow has been failing on `master` at the `Start supabase` step. Recent runs: - https://github.com/supabase/supabase/actions/runs/32092940311 - https://github.com/supabase/supabase/actions/runs/32131961447 In the Slack thread, Ivan Vasilov suggested trying a newer CLI and Alaister Young endorsed giving it a go. ## What is the new behavior? The workflow runs `supabase start` with CLI 2.114.0 instead of 2.76.14. The question this PR is trying to answer is simply **"does a newer CLI help this flake?"** It is not a diagnosis and not a claimed fix. If CI still fails at `Start supabase` on this branch, the bump can be kept or dropped on its own merits and the investigation continues elsewhere. ## Additional context **Verification status:** none locally. The bump was not exercised locally — this repo checkout has no `node_modules` (see the lockfile note above), so `pnpm typecheck`, `pnpm lint`, and `pnpm test:studio` were not run, and neither was `supabase start`. CI on this PR is the only signal. **Call-site compatibility check.** CLI 2.99/2.100 moved to a new TypeScript shell with a stricter argument parser: command-specific flags must now come *after* the subcommand. Both call sites in the root `package.json` already use that order, so no script changes are needed: ``` supabase stop --all --no-backup --workdir ./e2e/studio supabase start --exclude studio,mailpit --workdir ./e2e/studio ``` **Changelog entries between 2.76.14 and 2.114.0 that touch `supabase start` or local config.** Listed so reviewers know what changed in the range — **not** as a claim about what is failing in CI: - **2.112.0** — `supabase start` no longer hangs when analytics migrations fail; the analytics container exits and retries instead of booting against an unmigrated database ([#6093](https://github.com/supabase/cli/pull/6093)). - **2.112.0** — `supabase start` reuses existing volumes instead of failing when they already exist ([#6037](https://github.com/supabase/cli/pull/6037)); Kong reloads after `supabase db reset` ([#6017](https://github.com/supabase/cli/pull/6017)); custom auth email templates survive `db reset` ([#6065](https://github.com/supabase/cli/pull/6065)); `supabase start` works on SELinux-enforcing hosts ([#6000](https://github.com/supabase/cli/pull/6000)). - **2.106.0 — behavior change worth watching.** `[api].auto_expose_new_tables` now resolves to `false` when unset, and local start/reset revokes default Data API privileges for newly created `public` tables, sequences, and functions ([#5524](https://github.com/supabase/cli/pull/5524)). Neither `supabase/config.toml` nor `e2e/studio/supabase/config.toml` sets this key, so this default applies. If E2E specs create `public` objects and then read them through the Data API, they may need explicit `GRANT`s (the deprecated escape hatch is `auto_expose_new_tables = true`). - **2.106.0** — when the CLI detects a coding-agent environment, or `--agent yes` is passed, commands default to JSON output ([#5532](https://github.com/supabase/cli/pull/5532)). `e2e:setup:cli` already passes `--output json` to `supabase status` explicitly, so this should be a no-op here. - **2.100.0** — stricter flag ordering, covered above. - **2.112.0** — `functions deploy` no longer forwards `NPM_AUTH_TOKEN` into Docker bundling ([#6005](https://github.com/supabase/cli/pull/6005)). Not used by these workflows. - **2.107.0** — pg-delta is the default schema diff engine for `db diff` / `db pull` on new projects ([#5511](https://github.com/supabase/cli/pull/5511)). - Many bundled Docker image bumps across the range (`supabase/postgres` 17.6.1.087 → later patches, `postgres-meta`, `vector` 0.28.1 → 0.53.0, Studio image), plus `fix(analytics): wait for logflare before starting vector` (2.84.3) and `fix: use correct docker.sock binding with vector` (2.84.7). Full comparison: https://github.com/supabase/cli/compare/v2.76.14...v2.114.0 --- _Generated by [Claude Code](https://claude.ai/code/session_0143DrDMGnSSwuHebTPJv7ZY)_ --------- Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Ivan Vasilov <vasilov.ivan@gmail.com>
125 lines
3.7 KiB
YAML
125 lines
3.7 KiB
YAML
packages:
|
|
- apps/*
|
|
- packages/*
|
|
- blocks/*
|
|
- e2e/*
|
|
|
|
blockExoticSubdeps: true
|
|
engineStrict: true
|
|
updateNotifier: false
|
|
# Doesn't work because of Typescript issues with peer dependencies, see https://github.com/pnpm/pnpm/issues/9739
|
|
enableGlobalVirtualStore: false
|
|
|
|
catalog:
|
|
'@monaco-editor/react': ^4.7.0
|
|
'@sentry/nextjs': ^10.59.0
|
|
'@sentry/tanstackstart-react': ^10.59.0
|
|
'@supabase/auth-js': 2.112.3
|
|
'@supabase/postgrest-js': 2.112.3
|
|
'@supabase/realtime-js': 2.112.3
|
|
'@supabase/ssr': 0.10.2
|
|
'@supabase/supabase-js': 2.112.3
|
|
'@tanstack/react-router': ^1.169.2
|
|
'@tanstack/react-start': ^1.167.65
|
|
'@tanstack/react-table': ^8.21.3
|
|
'@types/node': ^22.0.0
|
|
'@types/react': ^19.2.14
|
|
'@types/react-dom': ^19.2.3
|
|
# TypeScript 7 has no programmatic API until 7.1, so `typescript` stays aliased
|
|
# to the 6.0-API compat package for tools that import it (typescript-eslint,
|
|
# Next.js build typechecking), while `@typescript/native` provides the native
|
|
# TS 7 `tsc` binary used by typecheck scripts.
|
|
# https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/
|
|
'@typescript/native': npm:typescript@~7.0.2
|
|
'@vitejs/plugin-react': ^6.0.1
|
|
'@vitest/coverage-v8': ^4.1.4
|
|
'@vitest/ui': ^4.1.4
|
|
lodash: ^4.18.1
|
|
lodash-es: ^4.18.1
|
|
monaco-editor: 0.52.2
|
|
next: ^16.2.11
|
|
next-themes: ^0.4.6
|
|
postcss: ^8.5.18
|
|
radix-ui: ^1.4.3
|
|
react: ^19.2.6
|
|
react-dom: ^19.2.6
|
|
recharts: ^2.15.4
|
|
tailwindcss: ^4.2.4
|
|
tsx: ^4.22.0
|
|
typescript: ~6.0.2
|
|
valtio: ^2.3.2
|
|
vite: ^8.0.16
|
|
vite-tsconfig-paths: ^6.1.1
|
|
vitest: ^4.1.4
|
|
zod: 3.25.76
|
|
|
|
allowBuilds:
|
|
'@parcel/watcher': false
|
|
'@sentry/cli': false
|
|
'@supabase/build-icons@file:packages/build-icons': set this to true or false
|
|
'@supabase/pg-meta@file:packages/pg-meta': set this to true or false
|
|
ai-commands@file:packages/ai-commands: set this to true or false
|
|
api-types@file:packages/api-types: set this to true or false
|
|
common@file:packages/common: set this to true or false
|
|
config@file:packages/config: set this to true or false
|
|
contentlayer2: false
|
|
core-js: false
|
|
dev-tools@file:packages/dev-tools: set this to true or false
|
|
es5-ext: false
|
|
esbuild: false
|
|
icons@file:packages/icons: set this to true or false
|
|
libpg-query: false
|
|
msw: false
|
|
node-pty: true
|
|
protobufjs: false
|
|
shared-data@file:packages/shared-data: set this to true or false
|
|
sharp: false
|
|
supabase: true
|
|
ui-patterns@file:packages/ui-patterns: set this to true or false
|
|
ui@file:packages/ui: set this to true or false
|
|
|
|
minimumReleaseAge: 4320
|
|
|
|
minimumReleaseAgeExclude:
|
|
- '@ai-sdk/*'
|
|
- '@supabase/*'
|
|
- '@supabase-labs/*'
|
|
- typescript
|
|
- '@typescript/*'
|
|
# First-party, published from supabase-community/mdast-jsx.
|
|
- mdast-jsx
|
|
# The following are excluded to fix vulnerablities.
|
|
- react-use
|
|
|
|
overrides:
|
|
'@ardatan/relay-compiler>immutable': ^3.8.3
|
|
'monaco-editor': 'catalog:'
|
|
'@mapbox/node-pre-gyp>tar': ^7.5.21
|
|
'@sentry/webpack-plugin>uuid': ^11.1.1
|
|
'@usercentrics/cmp-browser-sdk>uuid': ^11.1.1
|
|
braintrust>esbuild: ^0.28.1
|
|
braintrust>uuid: ^11.1.1
|
|
cacache>tar: ^7.5.21
|
|
dompurify: ^3.3.2
|
|
express-rate-limit>ip-address: ^10.1.1
|
|
# Pin h3 v1 to a single version so the Nuxt registry example (vue-blocks)
|
|
# doesn't end up with two copies (1.15.10 + 1.15.11) and hit nominal
|
|
# H3Event type mismatches. v2 (h3@2) is intentionally left untouched.
|
|
'h3@1': 1.15.11
|
|
lodash: 'catalog:'
|
|
lodash-es: 'catalog:'
|
|
mdx-bundler>uuid: ^11.1.1
|
|
node-gyp>tar: ^7.5.21
|
|
nodemailer: ^7.0.11
|
|
postcss: 'catalog:'
|
|
qs: ^6.15.2
|
|
refractor>prismjs: ^1.30.0
|
|
tmp: ^0.2.7
|
|
vite>esbuild: ^0.28.1
|
|
webpack: ^5.104.1
|
|
'codemirror-graphql>@codemirror/language': 6.11.0
|
|
'@esbuild-plugins/node-resolve>esbuild': ^0.28.1
|
|
|
|
patchedDependencies:
|
|
react-data-grid: patches/react-data-grid.patch
|