Upgrade dependencies (2025/11/30)

[pan93412]

• chore: upgrade dependencies
• chore: update schema

Summary by CodeRabbit

• New Features
  • Question visibility scoping: Control which users can view specific questions by assigning per-question visibility scopes. Questions without a scope remain visible to all users.
  • Enhanced filtering: Added comprehensive filtering and querying capabilities to manage questions based on visibility scope settings.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
dbplay-app	Ready	Preview	Comment	Nov 30, 2025 5:30am

[coderabbitai]

Walkthrough

A visibility scoping feature is added to questions in the GraphQL schema, enabling per-question visibility control through scope values with comprehensive filtering predicates. Runtime and development dependencies are upgraded to newer versions, including new Radix UI component libraries and framework updates.

Changes

Cohort / File(s)	Summary
GraphQL Schema & Generated Types schema.graphql, gql/graphql.ts	Introduces visibleScope field across Question types: CreateQuestionInput, Question, QuestionWhereInput (with 15 filtering predicates), and UpdateQuestionInput. Enables per-question visibility scoping with support for creation, querying, and updates.
Dependency Updates package.json	Updates multiple runtime dependencies (@ai-sdk/\, @graphql-codegen/\, lucide-react, next, react, react-dom, react-hook-form, shiki, streamdown, zod) and adds new @radix-ui component packages. Upgrades dev dependencies for TypeScript, ESLint, and GraphQL tooling; bumps canary versions for Next.js and React.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

• Schema coherence: Verify that all 15 visibleScope predicates in QuestionWhereInput align with the intended filtering capabilities and GraphQL conventions.
• Generated code accuracy: Confirm gql/graphql.ts is correctly generated from schema.graphql with proper TypeScript types for InputMaybe, Maybe, and Scalars.
• Dependency compatibility: Test dependency upgrades (especially major version changes to next, react, zod) for breaking changes and ensure no transitive dependency conflicts arise.
• Documentation alignment: Verify that the "Only users with this scope set can see the question" behavior is enforced in the resolver/backend logic (not visible in this diff).

Poem

🐰 A scope now visible, a question can hide—
Shown only to those with the right countryside,
Or open to all when the field runs bare,
Our GraphQL garden grows with care! 🌿

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Title check	⚠️ Warning	The pull request title describes upgrading dependencies, but the changeset includes significant schema changes (adding visibleScope feature to questions) alongside dependency updates, making the title incomplete and misleading about the actual scope of changes.	Revise the title to reflect all major changes, such as 'Add question visibility scope and upgrade dependencies' or split into separate PRs for schema changes and dependency upgrades.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch upgrade-dependencies-1130

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

package.json (1)

57-58: Inconsistent version pinning for PostHog packages.

posthog-js is pinned exactly (1.298.1) while posthog-node uses a caret range (^5.14.1). Consider aligning the pinning strategy for consistency — either pin both exactly for reproducibility or use caret ranges for both.

-    "posthog-js": "1.298.1",
-    "posthog-node": "^5.14.1",
+    "posthog-js": "^1.298.1",
+    "posthog-node": "^5.14.1",

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between c8d84d9 and d7baa43.

⛔ Files ignored due to path filters (1)

• pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml

📒 Files selected for processing (3)

• gql/graphql.ts (5 hunks)
• package.json (2 hunks)
• schema.graphql (5 hunks)

🔇 Additional comments (4)

schema.graphql (2)

74-78: LGTM - visibility scope field follows established patterns.

The visibleScope field addition is consistent with the ent-generated schema conventions. The predicates in QuestionWhereInput and the clearVisibleScope in UpdateQuestionInput follow the same patterns used for other nullable string fields.

---

747-751: Clarify semantics: null vs empty string for visibleScope.

The documentation states "Empty means visible to everyone" but the field is nullable (String without !). Consider clarifying whether null and "" (empty string) are treated equivalently, or if they have distinct meanings. This affects how consumers should query questions visible to everyone using visibleScopeIsNil vs checking for empty strings.

gql/graphql.ts (1)

1-2: Generated file - changes are consistent with schema.

This file is auto-generated by GraphQL Code Generator (indicated by /* eslint-disable */). The visibleScope additions in CreateQuestionInput, Question, QuestionWhereInput, and UpdateQuestionInput correctly mirror the schema.graphql changes.

package.json (1)

71-71: No compatibility concerns with Zod 4.x — current usage is compatible.

The codebase uses only Zod patterns that are compatible with v4: z.union(), z.object(), z.literal(), z.string().transform().describe(), z.number(), and safeParse(). None of the v4 breaking changes (error customization API and ZodError internals) affect these patterns. The breaking changes mentioned in the original review regarding .default() short-circuit behavior, z.record() schema requirements, and stricter .int() validation do not apply to the current codebase.