## 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?
Chore / build (ESLint config upgrade + lint cleanup).
## What is the current behavior?
`eslint-plugin-react-hooks` v5 (pulled in transitively by
`eslint-config-next` v15) doesn't recognize stable `useEffectEvent`, so
every effect that calls an effect-event handler needs an `eslint-disable
react-hooks/exhaustive-deps` to silence a false positive. There are 30
such dead disables across Studio.
## What is the new behavior?
Bumps `eslint-config-next` to v16, which pulls in
`eslint-plugin-react-hooks` v7 whose `exhaustive-deps` understands
`useEffectEvent`, and removes the 30 now-dead disable directives (and
their orphaned explanatory comments).
Supporting changes:
- **Flat-config migration**: v16 is a native flat-config array (v15 was
eslintrc), so `eslint-config-supabase` now spreads it directly instead
of bridging through `FlatCompat`.
- **React Compiler rules off**: v16 enables react-hooks v7's
`recommended`, which layers the React Compiler lint rules on top of the
two classic rules. These are switched off (derived dynamically from what
next enables) to keep this change scoped to the `exhaustive-deps`
improvement.
- **Plugin-registration fallout** (v16 scopes plugin registration to a
file glob rather than registering globally like FlatCompat did): stop
re-registering `@typescript-eslint` (shared) and `jsx-a11y` (studio);
scope our react / react-hooks / jsx-a11y rule overrides (studio, www) to
v16's plugin glob so they don't error on files outside it (e.g. `.cjs`).
- **Lint surface preserved**: v16's glob newly includes `.mts`/`.cts`
(v15 didn't lint them), which surfaced pre-existing errors in tooling
scripts. The shared config keeps the prior surface by leaving
`.mts`/`.cts` unlinted; linting them is left as a separate change.
- **Ratchet**: rebaselines `@tanstack/query/exhaustive-deps` 9 → 89. v15
forced next's `@babel/eslint-parser` onto `.ts` files, hiding these
deps; v16 parses `.ts` with `@typescript-eslint/parser` and correctly
surfaces the intentional `connectionString`-excluded-from-`queryKey`
pattern. Worth a follow-up to review whether any are real
cache-correctness bugs.
- Drops three now-dead devDeps from `eslint-config-supabase`:
`@eslint/eslintrc`, `@eslint/js`, `@typescript-eslint/eslint-plugin`.
Verified locally: `turbo run lint` → 7/7 packages pass with 0 errors;
Studio `lint:ratchet` passes; Prettier clean on changed files; typecheck
unaffected.
## Additional context
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Refined linting configuration and removed outdated lint suppressions
across Studio.
* Updated Next.js linting support and refreshed related development
configuration.
* Expanded lint baseline coverage for query-related code.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Problem
The Primary Database card in the project homepage diagram showed region
and instance size, but no live health data. Users had no quick way to
spot a high-disk or high-CPU situation without navigating to the
database report.
## Fix
Added a clickable metrics row at the bottom of the Primary Database card
showing CPU, Disk, and RAM as percentages, plus active/max connections
when available. Each metric is color-coded (warning at 80%, destructive
at 90%). Clicking the row navigates to the database observability
report.
The metrics are powered by a new \`useComputeMetrics\` hook that wraps
the existing \`useInfraMonitoringAttributesQuery\` and
\`useMaxConnectionsQuery\`, reusing the parse utilities already used by
the database infrastructure section. The \`metricColor\` threshold logic
is extracted into a separate util with unit tests.
## How to test
- Open the project homepage for a running project
- The Primary Database card should show a new bottom row: "CPU X% · Disk
X% · RAM X% · Y/Z conns"
- Values above 80% should appear in amber, above 90% in red
- Click the metrics row and confirm it navigates to
\`/project/<ref>/observability/database\`
- While metrics are loading, a spinner should appear in the row
- If the infra monitoring API is unavailable, the row should show
"Metrics unavailable" instead of zeroes
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Release Notes
* **New Features**
* Infrastructure configuration page now displays real-time compute
metrics (CPU, disk, memory usage) with color-coded usage indicators
based on thresholds.
* Connection information is displayed when available.
* Includes loading states and error handling for metric retrieval.
* **Tests**
* Added test coverage for metric color-coding logic.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Chris Opland