feat: deprecate condition argument, move all filtering to filter

[pyramation]

feat: v5-native connection filter plugin + deprecate condition argument

Summary

This PR makes two major changes:

1. New graphile-connection-filter package — A from-scratch PostGraphile v5-native connection filter plugin replacing the upstream postgraphile-plugin-connection-filter@3.0.0-rc.1. Full TypeScript source, 7 core plugins + relation filter plugins, same addConnectionFilterOperator API for satellite plugins (PostGIS, search, pgvector, textsearch). Includes toggleable relation filters (connectionFilterRelations option) and a computed column filter plugin.

2. Condition deprecation (BREAKING) — Moves the search (tsvector) and BM25 (pg_textsearch) plugins from isPgCondition scope to isPgConnectionFilter scope. Disables PgConditionArgumentPlugin and PgConditionCustomFieldsPlugin in the constructive preset. All tests updated from condition: {...} to filter: {...} syntax.

The pgvector plugin was already on filter and served as the reference implementation proving the getQueryBuilder() meta/ranking pattern works from filter scope.

Updates since last revision

• Removed connectionFilterAllowEmptyObjectInput option entirely — This was a band-aid option that toggled whether empty {} filter inputs were rejected. The root cause: GraphQL cannot distinguish "user didn't pass a filter argument" from "user passed filter: {}" — both resolve as {}. Instead of making this configurable, the fix is:

  • Top-level (ConnectionFilterArgPlugin.ts): applyPlan now checks if (value == null || isEmpty(value)) return; — treats empty filter as "no filter" (no-op, no WHERE clause added)
  • Nested contexts (logical operators, relation filters, per-column filters): Empty objects are always rejected — users can only reach these by explicitly passing {} inside and/or/not/relation fields, which is always a mistake
  • Removed the option from types.ts, preset.ts, augmentations.ts, ConnectionFilterAttributesPlugin.ts, and utils.ts
  • Removed the connectionFilterAllowEmptyObjectInput: true workaround from the pgvector integration test

• Previous fixes (CI now fully green, 40/40):

  • Schema snapshot: Reconstructed to include relation filter types, smart quote characters, and correct type ordering
  • send-email-link function: Migrated hardcoded condition: GraphQL queries to filter: syntax
  • Backward relations plugin: Added missing filterBy behavior registration for pgCodecRelation entities

Review & Testing Checklist for Human

• Verify ranking/scoring works from filter scope: The search and BM25 plugins rely on getQueryBuilder($condition) traversal to inject ts_rank/BM25 scores into the SELECT list and store meta for orderBy/computed fields. This traversal was proven on pgvector but should be verified end-to-end for tsvector and BM25 by running the search plugin and BM25 tests locally.
• Validate the schema snapshot is correct: The snapshot was reconstructed by parsing CI diff logs — not by running the test with --updateSnapshot. Run pnpm test -- -u in graphql/server-test locally to regenerate from scratch and confirm it matches what's committed.
• Check for other condition: references in the monorepo: The preset disables the condition argument entirely. Any GraphQL queries elsewhere in the codebase (app code, codegen files, other tests) that use condition: { ... } will break at runtime. Search for remaining usages.
• Verify the empty filter {} no-op behavior is correct: The top-level applyPlan now returns early for empty objects instead of throwing. Confirm this doesn't silently swallow cases where the user explicitly passes filter: {} and expects it to mean something. In nested contexts (and/or/not, relation filters, per-column filters), empty objects still throw — verify this is tested.
• Review the = {} as any scope destructuring pattern in plugin.ts (search) and bm25-search.ts: Both use scope: { isPgConnectionFilter, pgCodec } = {} as any — this silently falls through if the scope shape is unexpected. Confirm this matches how the filter plugin provides scope.
• Recommend testing the search/BM25 filter features manually in a running GraphQL server:
  • Search: allJobs(filter: { fullTextFullText: "apple" }) { nodes { id fullTextRank } orderBy: FULL_TEXT_RANK_DESC }
  • BM25: allArticles(filter: { bm25Body: { query: "database", threshold: -0.5 } }) { nodes { id bm25BodyScore } orderBy: BM25_BODY_SCORE_ASC }
  • Verify ranking/scoring populates, orderBy works, and threshold filtering applies correctly.

Notes

• The pnpm-lock.yaml diff is mostly formatting noise (multi-line → single-line resolution format) + the new graphile-connection-filter workspace dependency.
• The new filter plugin does NOT have its own test suite yet — it's only tested indirectly via satellite plugin tests (search, PostGIS, pgvector).
• Relation filters are enabled in the preset (connectionFilterRelations: true), allowing filters like allOrders(filter: { clientByClientId: { name: { startsWith: "Acme" } } }). These add many fields to the schema.
• The "graceful degradation" test in search plugin was updated — it now requires connection-filter (no longer tests standalone condition-based search since condition is deprecated).
• Semantic change: Top-level filter: {} (or omitting filter entirely) is now a no-op. Previously, with connectionFilterAllowEmptyObjectInput: false, this would throw "Empty objects are forbidden". This is more sensible behavior — an empty filter shouldn't constrain results anyway.

---

Session: https://app.devin.ai/sessions/cf88f3fd383b4421a5169ed01612899d
Requested by: @pyramation

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment and CI monitoring