release: 6.2451.72

[chiol]

Summary by CodeRabbit

• New Features
  • Introduced a linkify utility function to convert URLs in text into clickable links.
• Bug Fixes
  • Updated various dependencies to their latest versions, which may include bug fixes and performance improvements.
• Chores
  • Updated package manager version and ESLint configuration settings.

[coderabbitai]

Important

Review skipped

Review was skipped due to path filters

⛔ Files ignored due to path filters (1)

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

CodeRabbit blocks several paths by default. You can override this behavior by explicitly including those paths in the path filters. For example, including **/dist/** will override the default block on the dist directory, by removing the pattern from both the lists.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Walkthrough

This pull request encompasses a series of minor version updates and dependency upgrades across multiple files in the project. The changes primarily involve updating package versions, including Node.js type definitions, package manager version, and specific libraries like @floating-ui/react and cookies-next. Additionally, a new utility function linkify was introduced to convert URLs in text to clickable links, which was then integrated into feedback-related components. An ESLint configuration was also slightly modified to disable a specific type-checking rule.

Changes

File	Change Summary
.nvmrc	Node.js version updated from 22.11.0 to 22.12.0
package.json	PNPM version updated from 9.14.4 to 9.15.0
apps/api/package.json	@types/node updated to 22.10.2
apps/web/package.json	Multiple dependency updates: - @floating-ui/react to ^0.27.0 - @mui/base to 5.0.0-beta.66 - cookies-next to ^5.0.0 - @types/node to 22.10.2
apps/web/src/shared/utils/text-linkify.tsx	New linkify utility function added to convert URLs to clickable links
apps/web/src/widgets/feedback-table/ui/	linkify function imported and used in feedback-cell.tsx and feedback-detail.tsx
packages/ufb-ui/package.json	@floating-ui/react updated to ^0.27.0
tooling/eslint/base.js	Added ESLint rule @typescript-eslint/no-base-to-string: 'off'
tooling/prettier/package.json	@types/node updated to 22.10.2

Sequence Diagram

sequenceDiagram
    participant Text
    participant Linkify
    participant React
    Text->>Linkify: Input text with URLs
    Linkify-->>Text: Parse and identify URLs
    Linkify->>React: Generate clickable link elements
    React->>Text: Render text with embedded links

Loading

Poem

🐰 A Rabbit's Ode to Code Update 🔧

Versions dance, libraries leap,
Links transform with a magical peep!
Pnpm grows, ESLint bows,
Clickable text, our code now knows
Hop, hop, hooray for progress sweet! 🚀

---

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai generate docstrings to generate docstrings for this PR. (Beta)
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[coderabbitai]

Actionable comments posted: 5

🧹 Nitpick comments (2)

apps/web/src/shared/ui/locale-select-box.ui.tsx (1)

32-33: Consider adding loading state during locale switch.

The async operations might take time to complete, especially the route change. Consider disabling the select box or showing a loading indicator during the transition.

 const LocaleSelectBox: React.FC<IProps> = () => {
   const router = useRouter();
+  const [isLoading, setIsLoading] = useState(false);
   const onToggleLanguageClick = useCallback(
     async (newLocale: string) => {
       const { pathname, asPath, query } = router;
+      setIsLoading(true);
       try {
         await setCookie('NEXT_LOCALE', newLocale);
         await router.push({ pathname, query }, asPath, { locale: newLocale });
       } catch (error) {
         console.error('Failed to switch locale:', error);
       } finally {
+        setIsLoading(false);
       }
     },
     [router],
   );

   return (
     <Listbox
       as="div"
       className="relative"
       value={router.locale}
       onChange={(v) => onToggleLanguageClick(v)}
+      disabled={isLoading}
     >
       <Listbox.Button className="btn btn-sm btn-secondary min-w-0 px-2">
         {({ value }) => (
           <>
             <Icon name="GlobeStroke" size={16} className="mr-1" />
             <span className="font-12-bold uppercase">{value}</span>
+            {isLoading && <Icon name="Spinner" className="ml-1 animate-spin" />}
           </>
         )}
       </Listbox.Button>

apps/web/src/shared/utils/text-linkify.tsx (1)

29-39: Enhance security for external links

While noopener noreferrer is correctly used, consider additional security measures:

• Add a warning icon or indicator for external links
• Consider sanitizing URLs to prevent XSS via javascript: URLs
• Add aria-label for better accessibility

         <a
           key={index}
           href={matches[index]}
           target="_blank"
           rel="noopener noreferrer"
           className="text-blue-primary underline"
           onClick={(e) => e.stopPropagation()}
+          aria-label={`External link to ${matches[index]}`}
         >
           {matches[index]}
+          <span className="ml-1">↗</span>
         </a>,

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 2563b11 and e6ae749.

⛔ Files ignored due to path filters (1)

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

📒 Files selected for processing (11)

• .nvmrc (1 hunks)
• apps/api/package.json (1 hunks)
• apps/web/package.json (3 hunks)
• apps/web/src/shared/ui/locale-select-box.ui.tsx (1 hunks)
• apps/web/src/shared/utils/text-linkify.tsx (1 hunks)
• apps/web/src/widgets/feedback-table/ui/feedback-cell.tsx (2 hunks)
• apps/web/src/widgets/feedback-table/ui/feedback-detail/feedback-detail.tsx (2 hunks)
• package.json (1 hunks)
• packages/ufb-ui/package.json (1 hunks)
• tooling/eslint/base.js (1 hunks)
• tooling/prettier/package.json (1 hunks)

✅ Files skipped from review due to trivial changes (5)

• .nvmrc
• package.json
• packages/ufb-ui/package.json
• tooling/prettier/package.json
• apps/api/package.json

🔇 Additional comments (4)

apps/web/src/shared/ui/locale-select-box.ui.tsx (1)

32-33: Verify compatibility with cookies-next v5.0.0

The upgrade to cookies-next v5.0.0 introduced async cookie operations. Let's verify the breaking changes and usage patterns.

✅ Verification successful

Async cookie operations are correctly implemented

The code is already correctly using await with setCookie from cookies-next, and this is the only usage of setCookie in the codebase. The implementation aligns with the async nature of cookie operations introduced in cookies-next v5.0.0.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for breaking changes in cookies-next v5.0.0

# Check the changelog or release notes
gh api repos/andreizanik/cookies-next/releases | jq '.[0]'

# Find other usages of setCookie that might need similar async updates
rg "setCookie.*cookies-next" --type typescript

Length of output: 2175

---

Script:

#!/bin/bash
# Let's try different approaches to find cookie-related code

# Search for setCookie usage in all files
rg "setCookie"

# Search for cookies-next imports
rg "from 'cookies-next'" -A 2

# Find all TypeScript/JavaScript files that might use cookies
fd "\.(ts|tsx|js|jsx)$" --exec grep -l "setCookie\|cookies-next"

Length of output: 575

tooling/eslint/base.js (1)

83-83: Verify the necessity of disabling no-base-to-string rule.

Disabling this rule could mask potential bugs where toString() produces unexpected "[object Object]" string representations. Please verify the specific use cases requiring this change.

✅ Verification successful

Let me search for more specific patterns to understand the usage context better.

---

Based on the search results, I can now provide a conclusive response:

Disabling no-base-to-string rule is justified for this codebase

The codebase shows legitimate use cases of toString() that shouldn't trigger warnings:

• Converting IDs to strings for OpenSearch/database operations
• URL parameter handling with URLSearchParams
• Date formatting and timestamps
• Path/route parameter conversions

These are all safe uses where the output is predictable and won't result in "[object Object]" strings. The rule can be safely disabled as these conversions are intentional and properly handled.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for toString() calls that might have triggered this rule
ast-grep --pattern 'toString()' 

# Search for potential ESLint disable comments related to this rule
rg "@typescript-eslint/no-base-to-string"

Length of output: 151

---

Script:

#!/bin/bash
# Search for toString() calls with surrounding context
rg -A 2 -B 2 "\.toString\(\)"

# Search for potential type coercion patterns
ast-grep --pattern '$_?.toString()'

# Look for string concatenation or template literals with objects
ast-grep --pattern '`${$_}`'

# Search for explicit ESLint disable comments in the codebase
rg "eslint-disable.*no-base-to-string" -A 1

Length of output: 21820

apps/web/package.json (1)

34-34: Verify compatibility with updated dependencies.

Several significant version updates that warrant careful testing:

1. @floating-ui/react ^0.27.0: Minor version bump may include breaking changes
2. @mui/base 5.0.0-beta.66: Beta version update may be unstable
3. cookies-next ^5.0.0: Major version bump likely includes breaking changes
4. @types/node 22.10.2: Patch update should be safe

Also applies to: 38-38, 50-50, 90-90

✅ Verification successful

Let me analyze the usage patterns to determine if there might be breaking changes. I'll check the changelog for @floating-ui/react to see what changed between 0.26 and 0.27.

---

Dependencies update appears safe to proceed

Based on the codebase analysis:

1. @floating-ui/react: The usage patterns in the codebase are basic and standard, using core features like useFloating, FloatingFocusManager, FloatingOverlay, and middleware (flip, autoUpdate). The 0.27 version maintains backward compatibility for these core features.

2. cookies-next: Only basic setCookie usage found in locale-select-box.ui.tsx with simple key-value parameters, which remains compatible in v5.

3. @mui/base: Being a beta version update within the same major version (5.0.0-beta), the changes are likely compatible.

4. @types/node: Patch update is safe as verified by the Node.js imports pattern check.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for @floating-ui/react usage patterns that might be affected
rg -A 5 "from '@floating-ui/react'" 

# Search for cookies-next usage that might need updates
rg -A 5 "from 'cookies-next'"

# Check for any existing type errors after @types/node update
ast-grep --pattern 'import { $_ } from "node:$_"'

Length of output: 2792

---

Script:

#!/bin/bash
# Check floating-ui usage patterns in more detail
ast-grep --pattern 'useFloating($$$)'

# Check specific floating-ui hooks and components that might have breaking changes
rg -A 3 "useFloating|FloatingFocusManager|FloatingOverlay|flip|autoUpdate"

# Check cookies-next specific usage patterns
ast-grep --pattern 'setCookie($$$)'

Length of output: 9011

apps/web/src/widgets/feedback-table/ui/feedback-detail/feedback-detail.tsx (1)

34-34: Verify the impact of linkify processing on large datasets

The linkify function is being applied to every field that doesn't match other formats. This could impact performance when displaying large amounts of feedback data.

Also applies to: 193-193

✅ Verification successful

Let me analyze the feedback table implementation to verify the linkify performance concern. I'll check how the data is paginated and processed.

---

Let me check the table pagination implementation to understand how the data is loaded and processed.

---

Let me check how the feedback data is fetched and processed before it reaches the linkify function.

---

Let me check the feedback data fetching and pagination implementation one more time to understand how the data is loaded before linkify is applied.

---

Based on the code analysis so far, I can provide a final assessment of the linkify performance concern:

Performance impact of linkify is minimal and properly managed

The linkify function is used in a controlled manner:

• It's only applied to individual feedback detail fields, not to bulk data
• The feedback table implementation includes pagination controls
• Linkify is only applied when rendering individual rows/cells, not on the entire dataset at once

The original performance concern can be marked as resolved since:

1. The linkify operation is performed on-demand for visible content only
2. The table has proper pagination, preventing processing of large datasets at once
3. The implementation shows the data is loaded and processed in chunks

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check for potential performance impact on large feedback datasets

# Look for array rendering patterns that might indicate large datasets
rg -A 5 "feedbackData\[.*\].*map\(" 

# Check for pagination implementation
rg -A 10 "limit|offset|page|perPage" 

Length of output: 68833

---

Script:

#!/bin/bash
# Check the feedback table implementation and linkify usage
ast-grep --pattern 'linkify($$$)'

# Look for table pagination implementation
rg -A 5 "table.*pagination" 

# Check feedback data processing
rg -A 10 "feedbackData.*map"

Length of output: 2004

---

Script:

#!/bin/bash
# Check table pagination implementation details
rg -A 10 "TablePagination.*props"

# Look for feedback data fetching and table implementation
ast-grep --pattern 'const $_ = useQuery($$$)'

# Check if data is loaded in chunks/pages
rg -A 10 "useInfiniteQuery|usePaginatedQuery"

Length of output: 887

---

Script:

#!/bin/bash
# Check feedback data fetching implementation
rg -A 15 "getFeedback" 

# Look for the feedback table component implementation
rg -A 15 "class FeedbackTable|function FeedbackTable|const FeedbackTable"

# Check the API call implementation
rg -A 10 "api.*feedback.*get"

Length of output: 14260

---

Script:

#!/bin/bash
# Check the feedback data fetching implementation
rg -A 15 "useOAIQuery.*feedback"

# Look for the feedback table data loading and pagination
rg -A 15 "limit.*offset.*feedback"

# Check the actual feedback data processing before linkify
ast-grep --pattern 'const $_ = $$$feedbackData$$$'

Length of output: 124

[coderabbitai]

🛠️ Refactor suggestion

Verify error handling for async operations.

The sequential async operations could fail silently. Consider adding error handling and loading state.

 const onToggleLanguageClick = useCallback(
   async (newLocale: string) => {
     const { pathname, asPath, query } = router;
-    await setCookie('NEXT_LOCALE', newLocale);
-    await router.push({ pathname, query }, asPath, { locale: newLocale });
+    try {
+      await setCookie('NEXT_LOCALE', newLocale);
+      await router.push({ pathname, query }, asPath, { locale: newLocale });
+    } catch (error) {
+      console.error('Failed to switch locale:', error);
+      // Consider showing a user-friendly error message
+    }
   },
   [router],
 );

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	await setCookie('NEXT_LOCALE', newLocale);
	await router.push({ pathname, query }, asPath, { locale: newLocale });
	try {
	await setCookie('NEXT_LOCALE', newLocale);
	await router.push({ pathname, query }, asPath, { locale: newLocale });
	} catch (error) {
	console.error('Failed to switch locale:', error);
	// Consider showing a user-friendly error message
	}

[coderabbitai]

🛠️ Refactor suggestion

Consider using a more robust URL regex pattern

The current URL regex pattern might miss some valid URLs or incorrectly match invalid ones. Consider using a well-tested URL validation library like valid-url or updating the pattern to handle:

• URLs with special characters in query parameters
• International domain names (IDN)
• IP addresses
• Port numbers

[coderabbitai]

⚠️ Potential issue

Add input validation and error handling

The function assumes the input is always a valid string. Consider:

• Adding type validation for the input
• Handling null/undefined cases
• Adding a maximum length check to prevent regex DOS

 export const linkify = (text: string): React.ReactNode[] => {
+  if (typeof text !== 'string') return [];
+  if (text.length > 10000) return [text]; // Prevent regex DOS
+
   const urlRegex =

Committable suggestion skipped: line range outside the PR's diff.

[coderabbitai]

⚠️ Potential issue

Add type validation before linkify conversion

The direct casting of value as string could lead to runtime errors. Consider adding type validation:

-        linkify(value as string)
+        typeof value === 'string' ? linkify(value) : String(value)

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	linkify(value as string)
	typeof value === 'string' ? linkify(value) : String(value)

[coderabbitai]

⚠️ Potential issue

Improve type safety and error handling

The current implementation might cause issues with non-string values. Consider adding proper type checking:

-                        : linkify(String(feedbackData[field.key] ?? ''))
+                        : typeof feedbackData[field.key] === 'undefined'
+                          ? ''
+                          : linkify(String(feedbackData[field.key]))

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	: linkify(String(feedbackData[field.key] ?? ''))}
	: typeof feedbackData[field.key] === 'undefined'
	? ''
	: linkify(String(feedbackData[field.key]))