$ the-wire · showcase
Supabase CLI moves effect lint paths into config
By RepoJournal · Filed · About Supabase · Composed from the cited sources · methodology
The Supabase CLI's effect linting now reads its target paths from `.oxlintrc.effect.json` instead of hardcoded script arguments, making the config the single description of what gets linted.
The CLI's effect lint was tracked as a path list passed to `lint:effect:check` and `lint:effect:fix`, so the config never described what it applied to. Those paths now live in `.oxlintrc.effect.json` and both scripts just point at the config [1].
In practice, `ignorePatterns` becomes an allow list. `**` ignores everything, then one `!` entry re-includes each covered area, with `apps/cli/src/shared/compute/stacks/**` as an existing entry [1]. If you maintain a fork or shell script that calls these lint targets, your invocation no longer needs to supply paths.
On the evals desk, the automated releaser refreshed `apps/web/src/data/eval-results.json` from the latest eval run [2]. The same refresh also landed as a commit co-authored by mattrossman [3]. This is data churn, not a code change; nothing downstream is affected unless you consume that JSON directly.
In `supabase/mcp`, the `Sync Management API Types` workflow regenerated the Management API types from the current v1 and v2 OpenAPI specs [4]. Generated types moved with the specs; no hand-written MCP code is implicated.
Action items
- → Check any script invoking `lint:effect:check` or `lint:effect:fix` for now-redundant path arguments supabase/cli [plan]
- → Pull latest `apps/web/src/data/eval-results.json` if you consume eval results downstream supabase/evals [monitor]
References
- [1] chore(repo): move effect lint paths into config (CLI-2407) (#6574) ↗ supabase/cli
- [2] chore: refresh eval results ↗ supabase/evals
- [3] chore: refresh eval results (#288) ↗ supabase/evals
- [4] chore: regenerate management API types (#431) ↗ supabase/mcp
