Bump up Yorkie to v0.5.1

[chacha912]

What this PR does / why we need it?

Bump up Yorkie to v0.5.1

Any background context you want to provide?

What are the relevant tickets?

Fixes #

Checklist

• Added relevant tests or not required
• Didn't break anything

Summary by CodeRabbit

• New Features

  • Updated to Yorkie JavaScript SDK version 0.5.1, enhancing functionality and performance.
  • Improved directory structure representations in multiple example applications for better clarity and organization.

• Bug Fixes

  • Corrected export statements in example files to ensure proper accessibility of FILE_INFO.

• Chores

  • Updated environment variable values and dependency versions for consistency and to leverage new features.

[coderabbitai]

Walkthrough

The changes in this pull request involve updates to environment variables in the .env file, specifically incrementing version numbers and modifying a URL for the Yorkie JavaScript SDK. Additionally, the package.json file reflects an updated dependency version for the same SDK. Multiple files in the examples directory have modifications to the FILE_INFO constant, including structural changes and export status updates. A type definition in src/type.ts has also been adjusted.

Changes

File Path	Change Summary
.env	Updated NEXT_PUBLIC_YORKIE_VERSION and NEXT_PUBLIC_YORKIE_JS_VERSION to 0.5.1; modified NEXT_PUBLIC_JS_SDK_URL to point to version 0.5.1.
package.json	Updated yorkie-js-sdk dependency version from ^0.5.0 to ^0.5.1.
examples/nextjs-scheduler/fileInfo.ts	Updated FILE_INFO to describe directory structure for Next.js application.
examples/profile-stack/fileInfo.ts	Changed export status of FILE_INFO from non-exported to exported.
examples/react-tldraw/fileInfo.ts	Simplified FILE_INFO structure with fewer entries in children.
examples/react-todomvc/fileInfo.ts	Enhanced children array with detailed information about files in the src directory.
examples/vanilla-codemirror6/fileInfo.ts	Updated content of children array without structural changes.
examples/vanilla-quill/fileInfo.ts	Altered content of main.ts, updated handling of embed attribute and YorkiePresence type.
examples/vuejs-kanban/fileInfo.ts	Reformatted FILE_INFO object while preserving structure.
src/type.ts	Updated YorkiePresence type to have selection?: TextPosStructRange; instead of `selection: TextPosStructRange

Poem

🐇 In the garden where code does bloom,
New versions rise, dispelling gloom.
Yorkie's here, with updates bright,
Files restructured, all feels right.
Hopping through changes, we celebrate,
A world of code, oh, isn't it great? 🌼✨

---

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 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: 8

🧹 Outside diff range and nitpick comments (4)

examples/vuejs-kanban/fileInfo.ts (1)

2-2: LGTM! Consider splitting large object for improved maintainability.

The updated FILE_INFO constant correctly represents the directory structure and file contents for the Vue.js Kanban board application. The structure and content appear appropriate and consistent with a typical Vue.js project.

For improved maintainability, consider splitting this large object into smaller, more manageable pieces. For example:

const SRC_FILES = {
  // ... content of src directory
};

const CONFIG_FILES = {
  // ... content of configuration files
};

export const FILE_INFO: DirectoryInfo = {
  isFile: false,
  name: "vuejs-kanban",
  path: "/",
  children: [
    SRC_FILES,
    CONFIG_FILES,
    // ... other top-level files
  ]
};

This approach would make it easier to update and maintain specific parts of the file structure in the future.

examples/profile-stack/fileInfo.ts (1)

2-2: Consider adding documentation and automation for FILE_INFO.

While the content of FILE_INFO remains unchanged, its new export status increases its importance. Consider the following suggestions:

1. Add documentation explaining the purpose and structure of FILE_INFO.
2. If not already in place, consider implementing an automated process to update FILE_INFO when the project structure changes.

These steps will enhance maintainability and ensure FILE_INFO stays up-to-date with the actual project structure.

examples/react-todomvc/fileInfo.ts (1)

1-2: Consider the implications of exposing file contents

The FILE_INFO constant contains the entire file structure and content of the React TodoMVC example. While this can be useful for demonstration purposes, it's important to consider the following:

1. Security: Exposing the full content of all files, including potential sensitive information, could pose a security risk.
2. Performance: This large constant might impact the initial load time of the application.
3. Maintenance: Any changes to the files in the project would require manual updates to this constant.

Consider alternatives such as:

• Dynamically loading file contents when needed.
• Excluding sensitive information or configuration files.
• Implementing a build step to automatically generate this constant from the actual file structure.

examples/nextjs-scheduler/fileInfo.ts (1)

2-2: Consider adding JSDoc comments to utility functions.

The "utils" directory is well-organized with focused TypeScript files. To further improve code maintainability and developer experience, consider adding JSDoc comments to the exported functions in handlePeers.ts and parseDate.ts. This will provide better IntelliSense support and documentation.

Example improvement for parseDate.ts:

/**
 * Transforms a Date object into a DD-MM-YYYY string format.
 * @param {Date} date - The date to be transformed.
 * @returns {string} The formatted date string.
 */
export function parseDate(date: Date): string {
  // ... existing implementation
}

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 92b8193 and 346979a.

⛔ Files ignored due to path filters (1)

• package-lock.json is excluded by !**/package-lock.json

📒 Files selected for processing (9)

• .env (1 hunks)
• examples/nextjs-scheduler/fileInfo.ts (1 hunks)
• examples/profile-stack/fileInfo.ts (1 hunks)
• examples/react-tldraw/fileInfo.ts (1 hunks)
• examples/react-todomvc/fileInfo.ts (1 hunks)
• examples/vanilla-codemirror6/fileInfo.ts (1 hunks)
• examples/vanilla-quill/fileInfo.ts (1 hunks)
• examples/vuejs-kanban/fileInfo.ts (1 hunks)
• package.json (1 hunks)

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

• package.json

🧰 Additional context used

🔇 Additional comments (10)

.env (3)

2-2: LGTM: Version update for NEXT_PUBLIC_YORKIE_VERSION

The update from '0.5.0' to '0.5.1' aligns with the PR objective to bump up Yorkie to v0.5.1.

---

3-3: LGTM: Version update for NEXT_PUBLIC_YORKIE_JS_VERSION

The update from '0.5.0' to '0.5.1' is consistent with the change to NEXT_PUBLIC_YORKIE_VERSION and aligns with the PR objective.

---

4-5: Clarify: iOS and Android versions unchanged

While the main Yorkie version and JS SDK have been updated to 0.5.1, the iOS and Android versions remain at 0.4.24. Is this intentional? If not, should these versions also be updated to maintain consistency across platforms?

examples/vanilla-codemirror6/fileInfo.ts (1)

2-2: LGTM: Yorkie SDK version updated as expected.

The yorkie-js-sdk dependency has been correctly updated from ^0.5.0 to ^0.5.1 in the package.json file representation. This change aligns with the PR objective of bumping up Yorkie to v0.5.1.

Let's verify if this change is consistent across the project:

✅ Verification successful

Verified: yorkie-js-sdk has been successfully updated to ^0.5.1 with no remaining references to 0.5.0.

The package.json file correctly reflects the updated dependency:

"yorkie-js-sdk": "^0.5.1"

Additionally, no instances of version 0.5.0 were found in the codebase.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check if yorkie-js-sdk version is consistently updated across the project

# Test 1: Check package.json files
echo "Checking package.json files:"
rg --type json '"yorkie-js-sdk":\s*"\^0\.5\.1"' -g 'package.json'

# Test 2: Check for any remaining references to the old version
echo "Checking for any remaining references to version 0.5.0:"
rg "yorkie-js-sdk.*0\.5\.0" --type ts --type js --type json

Length of output: 358

examples/profile-stack/fileInfo.ts (1)

2-2: LGTM. Verify usage of exported constant.

The change to export the FILE_INFO constant looks good. This modification allows the constant to be used in other parts of the application.

To ensure this change is intentional and properly utilized, please verify the usage of FILE_INFO in other files:

examples/react-tldraw/fileInfo.ts (1)

2-2: Structure simplification: Potential impact on application

The FILE_INFO constant has been updated to simplify its structure while maintaining the overall hierarchy. This change could potentially impact other parts of the application that rely on this file structure.

To ensure this change doesn't break existing functionality, let's verify its usage:

Consider adding a comment explaining the purpose and structure of FILE_INFO to improve maintainability. For example:

/**
 * FILE_INFO: Represents the directory structure and file contents of the react-tldraw example.
 * This constant is used to [explain its purpose in the application].
 */
export const FILE_INFO: DirectoryInfo = { ... };

✅ Verification successful

FILE_INFO constant is widely used across multiple example projects

The FILE_INFO constant in examples/react-tldraw/fileInfo.ts is part of a broader pattern used across various example projects in the repository. This constant is utilized to define the file structure and contents for each demo project, including calendar, kanban, tldraw, simultaneous-cursors, todomvc, profile-stack, codemirror, and quill examples.

Given its widespread use, any changes to the structure or content of FILE_INFO should be carefully considered, as they could potentially impact multiple example projects. When modifying this constant, it's important to ensure that the changes are compatible with all the examples that rely on it.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for usages of FILE_INFO in the codebase
rg "FILE_INFO" --type typescript --type javascript

Length of output: 85

---

Script:

#!/bin/bash
# Search for usages of FILE_INFO in TypeScript and JavaScript files using correct type identifiers
rg "FILE_INFO" --type ts --type js

Length of output: 222863

examples/nextjs-scheduler/fileInfo.ts (3)

2-2: LGTM: FILE_INFO constant declaration.

The FILE_INFO constant is correctly exported and typed as DirectoryInfo. This allows for type checking and easier consumption of the file structure information throughout the application.

---

2-2: LGTM: App directory structure follows Next.js conventions.

The "app" directory structure adheres to Next.js 13+ conventions, with appropriate separation of concerns. The "utils" and "styles" subdirectories promote code organization and maintainability.

---

2-2: Overall, well-structured Next.js application with room for optimization.

The FILE_INFO constant provides a comprehensive view of a well-organized Next.js application. The structure follows best practices and conventions. Consider implementing the suggested optimizations for improved performance, maintainability, and developer experience. These include using CSS Modules, adding JSDoc comments, and optimizing React components.

examples/vanilla-quill/fileInfo.ts (1)

2-2: ⚠️ Potential issue

Handle optional selection property in YorkiePresence

In type.ts, the selection property in YorkiePresence has been made optional:

export type YorkiePresence = {
  username: string;
  color: string;
  selection?: TextPosStructRange;
};

Ensure that all usages of presence.selection in the codebase properly check for undefined before accessing it to prevent runtime errors.

Run the following script to identify usages of presence.selection without proper undefined checks:

This script searches for lines where presence.selection is used without preceding null or undefined checks. Review these instances to ensure that they handle the case where selection is undefined.

✅ Verification successful

All usages of presence.selection are properly checked for undefined.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Find all usages of presence.selection without null or undefined checks.

# Search for occurrences where presence.selection is accessed
rg --type typescript 'presence\.selection' \
  | rg -v 'if\s*\(.*presence\.selection' \
  | rg -v 'presence\.selection\s*!==' \
  | rg -v 'presence\.selection\s*===' \
  | rg -v 'presence\.selection\s*!=' \
  | rg -v 'presence\.selection\s*=='

Length of output: 260

---

Script:

#!/bin/bash
# Description: Find all usages of presence.selection without null or undefined checks.

# Search for occurrences where presence.selection is accessed in .ts and .tsx files
rg 'presence\.selection' --glob '*.ts' --glob '*.tsx' \
  | rg -v 'if\s*\(.*presence\.selection' \
  | rg -v 'presence\.selection\s*!==' \
  | rg -v 'presence\.selection\s*===' \
  | rg -v 'presence\.selection\s*!=' \
  | rg -v 'presence\.selection\s*=='

Length of output: 236

[coderabbitai]

💡 Codebase verification

Issue Found: New SDK URL is not accessible

The updated URL https://cdnjs.cloudflare.com/ajax/libs/yorkie-js-sdk/0.5.1/yorkie-js-sdk.js returned a 404 error, indicating that the resource is not available at this location. Please verify if version 0.5.1 has been correctly published on the CDN or consider reverting to the previous stable version 0.5.0 to ensure functionality.

🔗 Analysis chain

LGTM: Updated SDK URL, but verify accessibility

The URL update from version 0.5.0 to 0.5.1 is consistent with the other version changes. However, it's crucial to ensure that this new URL is accessible and the SDK is available at this location.

Please run the following script to verify the accessibility of the new SDK URL:

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the accessibility of the new Yorkie JS SDK URL

# Test: Check if the new SDK URL is accessible
curl -I https://cdnjs.cloudflare.com/ajax/libs/yorkie-js-sdk/0.5.1/yorkie-js-sdk.js

# Expected output: HTTP/2 200 or similar success status
# If not, the URL might not be valid or the resource might not be available yet

Length of output: 1213

[coderabbitai]

🛠️ Refactor suggestion

Improve consistency and clarity in the FILE_INFO structure

While the overall structure of FILE_INFO is well-organized, consider the following improvements:

1. Clarify the purpose of the isOpen property, as it's consistently set to false for all files. If it's not being used, consider removing it to simplify the structure.

2. For binary files (like images), represent the content more appropriately. For example:

   content: null, // or "binary_content"
   isBinary: true,

3. Standardize the language property. For example:

   language: file.endsWith('.ts') ? 'typescript' : 
             file.endsWith('.tsx') ? 'typescript' :
             file.endsWith('.js') ? 'javascript' :
             file.endsWith('.json') ? 'json' :
             file.endsWith('.html') ? 'html' :
             file.endsWith('.css') ? 'css' :
             file.endsWith('.md') ? 'markdown' :
             '',

4. Consider adding a size property for each file, which could be useful for performance optimizations or user information.

[coderabbitai]

🛠️ Refactor suggestion

Reconsider including full file contents in FILE_INFO

While the current structure effectively represents the directory tree, including full file contents within the FILE_INFO constant may lead to several issues:

1. Increased bundle size, potentially impacting load times.
2. Maintenance challenges when updating file contents.
3. Possible security concerns if sensitive information is included.

Consider refactoring this approach:

1. Store only metadata (file names, paths, and types) in FILE_INFO.
2. Implement a separate mechanism to load file contents on-demand.

Example refactored structure:

export const FILE_INFO: DirectoryInfo = {
  isFile: false,
  name: "react-tldraw",
  path: "/",
  children: [
    {
      isFile: false,
      name: "src",
      path: "/src",
      children: [
        {
          isFile: true,
          name: "hooks/types.ts",
          path: "/src/hooks/types.ts",
          language: "typescript"
        },
        // ... other files
      ]
    },
    // ... other directories
  ]
};

This approach would significantly reduce the size of FILE_INFO and make it easier to maintain. File contents could then be loaded asynchronously when needed.

[coderabbitai]

🛠️ Refactor suggestion

Consider using CSS Modules for better style scoping.

While the current CSS organization is good, consider fully embracing CSS Modules for all styles, not just page.module.css. This would provide better encapsulation and reduce the risk of style conflicts, especially in a growing application.

Example of converting calendar.css to a CSS Module:

1. Rename calendar.css to Calendar.module.css
2. Update the import in the corresponding component:

import styles from './styles/Calendar.module.css';

// Usage
<div className={styles.reactCalendar}>
  {/* ... */}
</div>

---

🛠️ Refactor suggestion

Consider performance optimizations for main components.

The Scheduler.tsx and page.tsx components are well-structured, but consider the following optimizations:

1. Use useMemo or useCallback for expensive computations or callback functions to prevent unnecessary re-renders.
2. Implement dynamic imports for large components to improve initial load time.
3. Consider using React.memo for child components that don't need frequent updates.

Example optimization for Scheduler.tsx:

import dynamic from 'next/dynamic';

const DynamicCalendar = dynamic(() => import('react-calendar'), {
  ssr: false,
  loading: () => <p>Loading calendar...</p>
});

// In your component
const memoizedEventHandler = useCallback((event: string) => {
  // ... event handler logic
}, [content, actions]);

---

💡 Codebase verification

Based on the analysis of the files, there are a few concerns and actions we need to take. Let's generate the final response:

The investigation has revealed some potential security issues, particularly with the handling of API keys. Here are the findings and recommendations:

1. API Key Exposure: The .env and .env.production files contain a public API key (NEXT_PUBLIC_EXAMPLES_API_KEY='cedaovjuioqlk4pjqn6g'). Even though it's prefixed with NEXT_PUBLIC_, exposing API keys in version control is not a secure practice.

   Recommendation: Remove this API key from the .env files and manage it securely outside of version control. Use a secret management system or environment variables set at runtime for production environments.

2. Empty Configuration Files: The nextjs-scheduler/.env and docker/docker-compose.yml files appear to be empty or inaccessible. This could be intentional for the nextjs-scheduler/.env, but the empty docker-compose file is unexpected.

   Recommendation: Verify the docker/docker-compose.yml file's existence and permissions. If it's supposed to contain configuration, ensure it's properly populated and secured.

3. Proper API Key Handling in Code: The BasicExampleView.tsx file demonstrates good practice by accepting the API key as a prop rather than hardcoding it.

   Recommendation: Continue this practice of passing sensitive information as props or environment variables rather than hardcoding them in the source code.

4. Further Investigation Needed: There might be other files containing sensitive information that we haven't checked.

   Recommendation: Conduct a thorough review of all configuration files, especially those not tracked in version control, to ensure no other sensitive information is exposed.

To address these issues:

1. Remove the NEXT_PUBLIC_EXAMPLES_API_KEY from .env and .env.production files.
2. Implement a secure method for managing and distributing API keys, especially for production environments.
3. Review and correct the docker/docker-compose.yml file if it's supposed to contain configuration.
4. Perform a comprehensive audit of all project files to identify and secure any other potential exposures of sensitive information.

🔗 Analysis chain

Review configuration files for sensitive information.

The FILE_INFO structure accurately represents a Next.js application. However, be cautious about including sensitive information in configuration files like .env or package.json. Ensure that no API keys, secrets, or other sensitive data are exposed in these files.

To check for potential sensitive information, you can run the following script:

---

Execute a comprehensive search for sensitive information across the entire codebase.

The initial check did not reveal any sensitive information in the specified files. To ensure no sensitive data is present elsewhere in the repository, please run the following script:

[/run_scripts]

---

To further investigate the potential exposure of sensitive information, we need to examine the content of some specific files. Let's run the following scripts to get more context:

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check for potential sensitive information in configuration files
grep -E '(api[_-]?key|secret|password|token)' .env .env.* package.json next.config.js

Length of output: 96

---

Script:

#!/bin/bash
# Comprehensive search for potential sensitive information in the entire codebase
rg -i --no-ignore --hidden '(api[_-]?key|secret|password|token)' .

Length of output: 232461

---

Script:

#!/bin/bash
# Check content of .env and .env.production files
echo "Contents of .env files:"
cat .env .env.production 2>/dev/null

echo -e "\nContents of nextjs-scheduler/.env:"
cat ./examples/nextjs-scheduler/.env 2>/dev/null

echo -e "\nContents of .env.production in the root directory:"
cat ./.env.production 2>/dev/null

# Check content of configuration files that might contain real credentials
echo -e "\nContents of docker/docker-compose.yml:"
cat ./docker/docker-compose.yml 2>/dev/null

# Check files that appear to have actual API keys or tokens
echo -e "\nContents of components/exampleView/BasicView/BasicExampleView.tsx:"
cat ./components/exampleView/BasicView/BasicExampleView.tsx 2>/dev/null

Length of output: 6397

[coderabbitai]

⚠️ Potential issue

Ensure safe handling of the embed attribute in toDeltaOperation function

In the toDeltaOperation function within main.ts, the embed value is returned directly:

if (embed) {
  return { insert: embed, attributes: restAttributes };
}

Without proper sanitization, this could introduce security vulnerabilities such as XSS attacks if embed contains malicious content. Consider sanitizing or validating the embed content before inserting it to ensure that only safe content is processed.

Apply this diff to sanitize the embed content:

 function toDeltaOperation<T extends TextValueType>(
   textValue: T,
 ): DeltaOperation {
   const { embed, ...restAttributes } = textValue.attributes ?? {};
   if (embed) {
+    const sanitizedEmbed = sanitizeEmbed(embed);
     return { insert: sanitizedEmbed, attributes: restAttributes };
   }

   return {
     insert: textValue.content || '',
     attributes: textValue.attributes,
   };
 }

+function sanitizeEmbed(embed: any): any {
+  // Implement sanitization logic here to prevent XSS or other vulnerabilities
+  // For example, you can use a library like DOMPurify if running in the browser
+  return embed;
+}

---

🛠️ Refactor suggestion

Consider externalizing large code strings for maintainability

The FILE_INFO constant includes large code strings embedded directly within the TypeScript file, which can make the code difficult to read and maintain. Consider storing these code contents in separate files and importing them or reading them dynamically. This approach will enhance readability and simplify code maintenance.

[hackerwins]

Thanks for your contribution.