chore(deps): bump next, vitest, colord, and tiptap in /moon - #2188
Conversation
Resolve campsite ids in CL reviewer timeline events, adapt vault to secp256k1 0.33, bump pnpm to 12.4.1, and clear kebab-case/toml warnings.
Add mega_cl.closed_at, set it on close/merge and clear on reopen, and render opened · closed/merged timestamps in the CL list UI.
Raise next/eslint-config-next to 16.3.3, vitest to 5, colord to 2.9.4, and align @tiptap/* on 3.30.5.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 83f547de04
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| case 'Comment': | ||
| icon = <CommentIcon /> | ||
| children = <CLComment conv={conv} id={id} whoamI={type} editorRef={editorRef} /> | ||
| if (parseReviewerEventComment(conv.comment)) { | ||
| icon = <PersonIcon size={24} className='text-tertiary' /> | ||
| children = <ReviewerEventItem conv={conv} /> |
There was a problem hiding this comment.
Distinguish reviewer events from ordinary comments
Ordinary non-reviewer CL comments are also stored with conv_type === 'Comment', so a user who submits text such as alice assigned a new reviewer bob takes this branch and gets rendered as a reviewer-assignment event even though no reviewer state changed. This creates a misleading timeline entry and removes the normal comment UI; identify these events through a dedicated type or reliable metadata rather than matching user-controlled prose.
Useful? React with 👍 / 👎.
| if (!comment) return null | ||
| const text = comment.trim() | ||
|
|
||
| let match = text.match(/^(\S+)\s+assigned a new reviewer\s+(\S+)$/) |
There was a problem hiding this comment.
Allow resolved display labels containing spaces
When an actor or reviewer resolves through the display_name or approval-display-name fallback, the backend now writes labels such as Jane Doe assigned a new reviewer John Smith, but these patterns require each label to be a single \S+ token. Such newly generated events therefore fail parsing and fall back to ordinary comments; preserve structured identity fields or parse around the fixed event phrase without assuming whitespace-free labels.
Useful? React with 👍 / 👎.
Unblocks the ESLint step on the moon dependency bump PR. Co-authored-by: Cursor <cursoragent@cursor.com>
No description provided.