Fix ESLint Rules to Ensure Proper Code Compliance #392
Conversation
WalkthroughThis pull request includes modifications to both backend and frontend codebases. Key changes involve updates to ESLint configurations for TypeScript, enhancing linting rules. Additionally, several services in the backend have simplified error handling by removing error parameters from catch blocks, directly throwing specific exceptions instead. In the frontend, type declarations for props in modal components have been changed from interfaces to type aliases, and a hook has been updated to improve dependency management. Overall, these changes aim to streamline code and improve consistency. Changes
Possibly related PRs
Suggested labels
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? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
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)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Outside diff range and nitpick comments (16)
backend/src/documents/documents.service.ts (3)
33-35: Consider adding error logging for debugging purposes.
The simplified error handling is cleaner and follows best practices. However, consider adding error logging before throwing the UnauthorizedException to help with debugging in production environments.
} catch {
+ console.error('Failed to validate sharing token:', sharingToken);
throw new UnauthorizedException("Invalid sharing token");
}45-47: Consider adding error logging for debugging purposes.
The simplified error handling is appropriate. However, consider adding error logging before throwing the NotFoundException to aid in troubleshooting.
} catch {
+ console.error('Document not found with ID:', documentId);
throw new NotFoundException("Document not found");
}Rate limiting implementation recommended for document sharing token validation
The codebase currently lacks rate limiting protection for the document sharing token validation endpoint. This could make the system vulnerable to brute force attacks where malicious actors attempt to guess valid sharing tokens.
Recommended actions:
- Implement rate limiting using a package like
@nestjs/throttler - Apply rate limits at the endpoint level to restrict the number of token validation attempts
- Consider implementing progressive delays or temporary IP blocks after multiple failed attempts
🔗 Analysis chain
Line range hint 16-54: Consider implementing rate limiting for security.
While the error handling is secure and doesn't leak sensitive information, consider implementing rate limiting for this endpoint to prevent brute force attempts on sharing tokens.
Let's check if rate limiting is implemented at the controller level:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for rate limiting decorators or middleware
# Expected: Find rate limiting implementation in the documents controller or middleware
# Search for rate limiting decorators
rg -l "RateLimit|ThrottlerGuard|@UseGuards" "backend/src/documents"
# Search for rate limiting middleware
rg -l "RateLimitMiddleware|ThrottlerModule" "backend/src"
Length of output: 125
Script:
#!/bin/bash
# Let's broaden our search to check for any rate limiting implementation
# Check for common rate limiting packages and implementations
# Check package.json for rate limiting dependencies
echo "Checking package.json for rate limiting packages:"
cat package.json | grep -i "throttle\|rate-limit\|express-rate-limit"
# Search for any rate limiting related code in the entire backend
echo -e "\nSearching for rate limiting related code:"
rg -i "throttle|ratelimit|rate.?limit" backend/src
# Check for any custom middleware implementations
echo -e "\nChecking for middleware implementations:"
fd -e ts middleware backend/src
Length of output: 463
backend/src/workspace-users/workspace-users.service.ts (2)
Line range hint 23-27: Consider enhancing error handling for better observability.
While the simplified error handling is cleaner and consistent with other services, consider preserving error information for debugging purposes without breaking ESLint rules.
Here's a suggested improvement that maintains ESLint compliance while adding better error context:
- } catch {
+ } catch (error: unknown) {
+ // Log error for debugging while maintaining clean error messages for users
+ console.error('Workspace access check failed:', error);
throw new NotFoundException(
"The workspace does not exist, or the user lacks the appropriate permissions."
);The suggested improvements are valid but need to be refined
The review comment's suggestions are partially valid, but need to be adjusted based on the existing patterns found:
- The
pageSizeparameter is already validated throughParseIntPipeat the controller level with a default value of 10, making the suggested validation partially redundant. - Error handling for permissions is properly implemented across all workspace-related services.
- The cursor handling suggestion is valid as there's no validation for cursor format.
- The main query operation could benefit from error handling as suggested.
Recommended refinements to the original suggestion:
async findMany(
userId: string,
workspaceId: string,
pageSize: number,
cursor?: string
): Promise<FindWorkspaceUsersResponse> {
- // Validate input parameters
- if (pageSize <= 0 || pageSize > 100) {
- throw new BadRequestException('Page size must be between 1 and 100');
- }
+ // Optional: Add upper bound check if needed
+ if (pageSize > 100) {
+ throw new BadRequestException('Page size cannot exceed 100');
+ }
try {
await this.prismaService.userWorkspace.findFirstOrThrow({
where: {
userId,
workspaceId,
},
});
} catch {
throw new NotFoundException(
"The workspace does not exist, or the user lacks the appropriate permissions."
);
}
const additionalOptions: Prisma.UserFindManyArgs = {};
if (cursor) {
try {
additionalOptions.cursor = { id: cursor };
} catch {
throw new BadRequestException('Invalid cursor format');
}
}
try {
const workspaceUserList = await this.prismaService.user.findMany({
// ... existing query ...
});
} catch (error) {
throw new InternalServerErrorException('Failed to fetch workspace users');
}🔗 Analysis chain
Line range hint 10-20: Consider adding additional error handling and input validation.
The method could benefit from:
- Error handling for the main query operation
- Input validation for the pageSize parameter
- More robust cursor handling
Let's verify if similar patterns exist in other services:
Consider these improvements:
async findMany(
userId: string,
workspaceId: string,
pageSize: number,
cursor?: string
): Promise<FindWorkspaceUsersResponse> {
+ // Validate input parameters
+ if (pageSize <= 0 || pageSize > 100) {
+ throw new BadRequestException('Page size must be between 1 and 100');
+ }
+
try {
await this.prismaService.userWorkspace.findFirstOrThrow({
where: {
userId,
workspaceId,
},
});
} catch {
throw new NotFoundException(
"The workspace does not exist, or the user lacks the appropriate permissions."
);
}
const additionalOptions: Prisma.UserFindManyArgs = {};
if (cursor) {
+ try {
additionalOptions.cursor = { id: cursor };
+ } catch {
+ throw new BadRequestException('Invalid cursor format');
+ }
}
+ try {
const workspaceUserList = await this.prismaService.user.findMany({
take: pageSize + 1,
select: {
id: true,
nickname: true,
updatedAt: true,
createdAt: true,
},
where: {
userWorkspaceList: {
some: {
workspaceId: {
equals: workspaceId,
},
},
},
},
orderBy: {
id: "desc",
},
...additionalOptions,
});
+ } catch (error: unknown) {
+ console.error('Failed to fetch workspace users:', error);
+ throw new InternalServerErrorException('Failed to fetch workspace users');
+ }Also applies to: 39-63
Let me check the implementation of these pagination methods to see if they have proper error handling and input validation.
Let me check for any existing error handling patterns in these services to make a more informed decision.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for pagination handling patterns in other services
rg -A 5 "pageSize.*cursor" --type ts
Length of output: 1432
Script:
#!/bin/bash
# Check implementation of findMany methods in these services
ast-grep --pattern 'async findMany($$$) {
$$$
}'
# Also check for any existing pageSize validation
rg "pageSize.*\d+" --type ts
Length of output: 315
Script:
#!/bin/bash
# Check for try-catch blocks and error handling in these services
rg -A 5 "try\s*{" --type ts backend/src/workspace*
rg -A 5 "catch" --type ts backend/src/workspace*
# Check for any validation decorators or patterns
rg "@.*Param|@.*Query" --type ts backend/src/workspace*
Length of output: 7803
frontend/src/components/modals/ChangeNicknameModal.tsx (1)
Line range hint 11-77: Consider these improvements for better maintainability and UX.
While the implementation is functional, here are some suggestions to enhance it:
- Consider extracting the debounce delay to a constant or configuration
- Consider internationalizing error messages for better i18n support
- Consider showing loading states during API calls
- Consider consolidating the nickname state management
Here's how you could implement these improvements:
+ const NICKNAME_DEBOUNCE_DELAY = 500; // in milliseconds
+
function ChangeNicknameModal(props: ChangeNicknameModalProps) {
- const [nickname, setNickname] = useState("");
- const [debouncedNickname, setDebouncedNickname] = useState("");
+ const [debouncedNickname, setDebouncedNickname] = useState("");
const { data: conflictResult } = useCheckNameConflictQuery(debouncedNickname);
- const { mutateAsync: updateUserNickname } = useUpdateUserNicknameMutation();
+ const { mutateAsync: updateUserNickname, isLoading } = useUpdateUserNicknameMutation();
const errorMessage = useMemo(() => {
if (conflictResult?.conflict) {
- return "Already Exists";
+ return t('errors.nicknameExists');
}
return null;
}, [conflictResult?.conflict]);
useDebounce(
() => {
- setDebouncedNickname(nickname);
+ setDebouncedNickname(values.nickname);
},
- 500,
+ NICKNAME_DEBOUNCE_DELAY,
- [nickname]
+ [values.nickname]
);
- const handleNicknameChange = (e: React.ChangeEvent<HTMLInputElement | HTMLTextAreaElement>) => {
- setNickname(e.target.value);
- };
// ... rest of the component
<Button
type="submit"
variant="contained"
size="large"
- disabled={Boolean(errorMessage)}
+ disabled={Boolean(errorMessage) || isLoading}
>
- OK
+ {isLoading ? <CircularProgress size={24} /> : t('common.ok')}
</Button>frontend/src/hooks/useYorkieDocument.ts (1)
32-37: Document the default syncLoopDuration value.
Add a comment explaining why 200ms was chosen as the default value and what impact this configuration has on synchronization behavior.
+// Default sync loop duration of 200ms provides a balance between
+// real-time collaboration responsiveness and server load
const syncLoopDuration = Number(searchParams.get("syncLoopDuration")) || 200;
const newClient = new yorkie.Client(YORKIE_API_ADDR, {
apiKey: YORKIE_API_KEY,
token: yorkieToken,
syncLoopDuration,
});backend/src/files/files.service.ts (2)
48-50: Consider enhancing error message clarity while maintaining security.
While the simplified error handling is cleaner, the generic message "Client unauthorized" might make debugging harder for developers. Consider using a more descriptive message that doesn't leak sensitive details.
} catch {
- throw new UnauthorizedException("Client unauthorized.");
+ throw new UnauthorizedException("Access denied: Invalid or inaccessible workspace.");
}48-50: Consider implementing centralized error handling.
The current approach of simplified error handling is good, but consider implementing a centralized error handling strategy using NestJS filters. This would provide consistent error responses across all services while maintaining the simplified catch blocks.
Example implementation:
// http-exception.filter.ts
@Catch()
export class AllExceptionsFilter implements ExceptionFilter {
catch(exception: unknown, host: ArgumentsHost) {
const ctx = host.switchToHttp();
const response = ctx.getResponse();
// Handle different error types while maintaining security
if (exception instanceof PrismaClientKnownRequestError) {
// Handle Prisma errors
} else if (exception instanceof S3ServiceException) {
// Handle S3 errors
}
// ... other error types
}
}Also applies to: 77-79
backend/src/workspaces/workspaces.service.ts (1)
Line range hint 117-121: Fix typo in error message.
There's a typo in the error message: "Worksapce" should be "Workspace".
- "Worksapce does not exist, or the user lacks the appropriate permissions."
+ "Workspace does not exist, or the user lacks the appropriate permissions."backend/src/workspace-documents/workspace-documents.service.ts (6)
Line range hint 33-37: Consider more specific error handling
The current catch block loses valuable error information and uses a generic message that doesn't distinguish between different failure cases (workspace not found vs. permission denied).
Consider handling specific error types:
- } catch {
+ } catch (error) {
+ if (error instanceof Prisma.PrismaClientKnownRequestError) {
+ if (error.code === 'P2025') { // Not Found error
+ throw new NotFoundException("Workspace not found");
+ }
+ }
throw new NotFoundException(
- "The workspace does not exist, or the user lacks the appropriate permissions."
+ "You don't have permission to access this workspace"
);
}Line range hint 53-57: Implement consistent error handling pattern
Similar to the previous method, this catch block uses a generic error message. Consider implementing a consistent error handling pattern across all methods.
Consider creating a custom error handling utility:
// error-handler.util.ts
export function handleWorkspaceAccessError(error: unknown): never {
if (error instanceof Prisma.PrismaClientKnownRequestError) {
if (error.code === 'P2025') {
throw new NotFoundException("Workspace not found");
}
}
throw new ForbiddenException("Insufficient permissions");
}Then use it consistently across all methods:
- } catch {
+ } catch (error) {
+ handleWorkspaceAccessError(error);
}Line range hint 81-85: Enhance error handling and add input validation
The error handling follows the same overly generic pattern. Additionally, the method lacks input validation for pagination parameters.
- Implement proper error handling as suggested above
- Add input validation:
async findMany(
userId: string,
workspaceId: string,
pageSize: number,
cursor?: string
): Promise<FindWorkspaceDocumentsResponse> {
+ if (pageSize <= 0 || pageSize > 100) {
+ throw new BadRequestException('Page size must be between 1 and 100');
+ }
try {Line range hint 149-153: Separate database operations for better error handling
The current implementation combines workspace and document queries in a single try-catch block, making it impossible to provide specific error messages.
Consider separating the operations:
async findOne(userId: string, workspaceId: string, documentId: string) {
try {
await this.prismaService.userWorkspace.findFirstOrThrow({
where: {
userId,
workspaceId,
},
});
+ } catch (error) {
+ handleWorkspaceAccessError(error);
+ }
+
+ try {
const document = await this.prismaService.document.findUniqueOrThrow({
where: {
id: documentId,
},
});
return document;
- } catch {
- throw new NotFoundException(
- "The workspace or document does not exist, or the user lacks the appropriate permissions."
+ } catch (error) {
+ if (error instanceof Prisma.PrismaClientKnownRequestError) {
+ throw new NotFoundException("Document not found");
+ }
+ throw new NotFoundException(
+ "Unable to retrieve the document"
);
}
}Line range hint 179-183: Add input validation and improve error handling
The method needs input validation for role and expirationDate parameters, and better error handling for the database operations.
Add input validation and separate error handling:
async createSharingToken(
userId: string,
workspaceId: string,
documentId: string,
role: ShareRole,
expirationDate: Date
): Promise<CreateWorkspaceDocumentShareTokenResponse> {
+ if (expirationDate <= new Date()) {
+ throw new BadRequestException('Expiration date must be in the future');
+ }
+
let document: Document;
try {
await this.prismaService.userWorkspace.findFirstOrThrow({
where: {
userId,
workspaceId,
},
});
+ } catch (error) {
+ handleWorkspaceAccessError(error);
+ }
+ try {
document = await this.prismaService.document.findUniqueOrThrow({
where: {
id: documentId,
workspaceId,
},
});
- } catch {
- throw new NotFoundException(
- "The workspace or document does not exist, or the user lacks the appropriate permissions."
+ } catch (error) {
+ if (error instanceof Prisma.PrismaClientKnownRequestError) {
+ throw new NotFoundException("Document not found");
+ }
+ throw new NotFoundException(
+ "Unable to retrieve the document"
);
}Line range hint 199-240: Improve error handling in Yorkie API communication
The current implementation has potential issues with error handling and resource cleanup.
Consider using a try-finally block and proper error handling:
async findManyFromYorkie(
documentKeyList: Array<string>
): Promise<FindDocumentsFromYorkieResponse | undefined> {
+ const client = connect(`${this.configService.get<string>("YORKIE_API_ADDR")}`);
return new Promise((resolve, reject) => {
- const client = connect(`${this.configService.get<string>("YORKIE_API_ADDR")}`);
+ try {
client.on("error", (err) => reject(err));
const requestBody = JSON.stringify({
project_name: this.configService.get<string>("YORKIE_PROJECT_NAME"),
document_keys: documentKeyList,
include_snapshot: false,
});
const req = client.request({
":method": "POST",
":path": "/yorkie.v1.AdminService/GetDocuments",
"Content-Type": "application/json",
"content-length": Buffer.byteLength(requestBody),
Authorization: this.configService.get<string>("YORKIE_PROJECT_SECRET_KEY"),
});
req.write(requestBody);
req.setEncoding("utf8");
let data = "";
req.on("data", (chunk) => {
data += chunk;
});
req.on("end", () => {
- client.close();
resolve(JSON.parse(data) as FindDocumentsFromYorkieResponse);
});
req.end();
+ } finally {
+ client.close();
+ }
});
}📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (11)
- backend/eslint.config.mjs (1 hunks)
- backend/src/documents/documents.service.spec.ts (0 hunks)
- backend/src/documents/documents.service.ts (2 hunks)
- backend/src/files/files.service.ts (2 hunks)
- backend/src/workspace-documents/workspace-documents.service.ts (5 hunks)
- backend/src/workspace-users/workspace-users.service.ts (1 hunks)
- backend/src/workspaces/workspaces.service.ts (4 hunks)
- frontend/eslint.config.mjs (1 hunks)
- frontend/src/components/modals/ChangeNicknameModal.tsx (1 hunks)
- frontend/src/components/modals/ShareModal.tsx (1 hunks)
- frontend/src/hooks/useYorkieDocument.ts (1 hunks)
💤 Files with no reviewable changes (1)
- backend/src/documents/documents.service.spec.ts
🔇 Additional comments (8)
backend/eslint.config.mjs (1)
23-24: LGTM! Verify rule precedence.
The addition of recommended rules from both plugins is a good practice. However, let's verify there are no conflicting rules between the plugins.
Consider adding a comment to document the rule precedence, as later rules override earlier ones. This helps maintainers understand which plugin's rules take precedence in case of conflicts:
rules: {
+ // TypeScript ESLint recommended rules (can be overridden by Prettier)
...typescriptPlugin.configs.recommended.rules,
+ // Prettier recommended rules (take precedence over TypeScript ESLint)
...prettierPlugin.configs.recommended.rules,✅ Verification successful
Rule spreading order is correct and safe
The ESLint configuration is well-structured and the order of spreading rules is appropriate:
- TypeScript ESLint rules are spread first as base rules
- Prettier rules are spread after, allowing them to override any formatting-related TypeScript rules
- Specific rule customizations are defined last, giving them highest precedence
The suggested documentation comment is not necessary as the configuration follows the standard ESLint rule precedence pattern where later rules naturally override earlier ones.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for potential rule conflicts between typescript-eslint and prettier
# Search for any documentation about conflicting rules
rg -i "conflict.*prettier.*typescript" README.md docs/
rg -i "typescript-eslint.*prettier.*conflict" README.md docs/
# Look for any existing override patterns that might indicate known conflicts
ast-grep --pattern 'rules: {
$$$
"@typescript-eslint/$_": "off",
"prettier/$_": $$$,
$$$
}'
Length of output: 222
Script:
#!/bin/bash
# Let's try a different approach to check the ESLint configuration
# First, let's see the full content of the ESLint config file
cat backend/eslint.config.mjs
# Also check for any eslint-related dependencies in package.json
cat backend/package.json | grep -A 5 -B 5 "eslint"
# Look for any existing ESLint configuration files that might have been replaced
fd -e json -e js -e cjs -e yaml -e yml -E "*.config.*" . | grep -i eslint
Length of output: 1442
frontend/eslint.config.mjs (2)
28-30: Verify TypeScript-specific rules are properly enforced.
The configuration now includes the recommended TypeScript rules, which is great for ensuring type safety and best practices.
Let's verify the TypeScript rules are being properly applied:
#!/bin/bash
# Description: Verify TypeScript rules are being enforced
# Test: Look for TypeScript-specific lint configurations or overrides in the codebase
rg -g '!node_modules' -g '!dist' '@typescript-eslint|// @ts-'28-30: Consider rule precedence in spread operations.
The order of spreading recommended rules is important as later rules can override earlier ones. The current order is:
- react-hooks
- prettier
- typescript-eslint
This seems reasonable as TypeScript rules should take precedence over Prettier formatting rules, but you might want to verify that no critical rules are being overridden.
Let's check for any potential rule conflicts:
✅ Verification successful
Rule precedence order is correctly configured
The current configuration shows a well-structured rule precedence where:
- A specific rule for react-refresh is defined first
- React hooks rules are spread next
- Prettier rules follow
- TypeScript rules come last, giving them the highest precedence
This order is optimal because:
- TypeScript rules having the highest precedence ensures type-safety rules aren't overridden
- Prettier rules are positioned correctly between React and TypeScript rules
- No rule conflicts are present in the codebase (no ESLint disable directives found)
- The backend configuration follows a similar pattern, validating this approach
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for overlapping rules between plugins that might cause conflicts
# Test 1: Extract and compare rules from each plugin
echo "Checking for rule overlaps between plugins..."
ast-grep --pattern 'rules: {
$$$
}'
# Test 2: Search for any ESLint-related warning comments that might indicate rule conflicts
rg -g '!node_modules' -g '!dist' '// eslint-disable|/\* eslint-disable \*/|eslint-disable-next-line'
Length of output: 4008
Script:
#!/bin/bash
# Let's try a different approach to check the rules configuration
# Check the actual ESLint config file content
echo "Checking ESLint config content:"
cat frontend/eslint.config.mjs
# Check if there are any explicit rule overrides or conflicts in the config
echo -e "\nChecking for any explicit rule configurations:"
rg -g '!node_modules' -g '!dist' 'rules:' -A 10 -B 2
# Look for any ESLint related comments that might indicate rule conflicts
echo -e "\nChecking for ESLint disable directives in TypeScript/JavaScript files:"
rg -g '!node_modules' -g '!dist' -g '*.{ts,tsx,js,jsx,mjs}' '// eslint-disable|/\* eslint-disable \*/|eslint-disable-next-line'
Length of output: 3451
frontend/src/components/modals/ChangeNicknameModal.tsx (1)
8-8: LGTM! Type alias is appropriate here.
The change from interface to type alias is a good choice for this simple type definition that uses Omit. This aligns with TypeScript best practices and maintains consistency with other modal components.
frontend/src/hooks/useYorkieDocument.ts (1)
30-42: LGTM! Dependency array correctly updated.
The addition of searchParams to the dependency array ensures that the client is properly recreated when URL parameters change.
backend/src/files/files.service.ts (1)
77-79: LGTM! Verify S3 error scenarios.
The error handling is appropriate for missing files. However, S3 operations can fail for various reasons (permissions, network, etc.).
Let's verify the error handling coverage:
✅ Verification successful
Let me gather more information about the error handling patterns in the codebase.
Let me check one more thing to see if there are any other S3-related error handling patterns in the codebase.
Error handling for S3 operations is appropriate and consistent
The error handling implementation is correct and follows the established pattern in the codebase:
- The catch block appropriately maps S3 access failures to a
NotFoundException - The generic error message maintains security by not exposing internal details
- Similar error handling pattern is used consistently across the service
- The 404 status code is the correct choice for missing S3 objects, as it aligns with HTTP semantics
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for S3 error handling patterns in similar services
rg -A 5 "new S3Client|GetObjectCommand|PutObjectCommand" --type ts
Length of output: 1674
Script:
#!/bin/bash
# Search for error handling patterns in files.service.ts
rg -B 5 -A 5 "catch" backend/src/files/files.service.ts
Length of output: 648
Script:
#!/bin/bash
# Search for S3-related error handling in the entire codebase
ast-grep --pattern 'try {
$$$
new GetObjectCommand($$$)
$$$
} catch ($_) {
$$$
}'
Length of output: 91
backend/src/workspaces/workspaces.service.ts (2)
Line range hint 64-68: LGTM! Good security practice in error handling.
The error message appropriately combines workspace existence and permission checks, preventing potential information disclosure.
Line range hint 64-68: LGTM! Consistent error handling pattern across the service.
The error handling follows a consistent pattern:
- Appropriate use of NestJS exceptions
- Removal of unused error parameters
- Security-conscious error messages that don't leak internal state
This aligns well with NestJS best practices and improves code maintainability.
Also applies to: 117-121, 157-159, 167-169
What this PR does / why we need it:
This PR updates the ESLint rules to ensure that they are correctly applied to the codebase. During the transition from CommonJS (cjs) to ECMAScript Modules (mjs) in a previous PR (#361), it was identified that the ESLint settings were not functioning as intended. The plugin was initialized, but the rules were not being enforced properly.
After identifying the issue, the ESLint rules have been corrected and adjusted, and necessary code changes were made to ensure compliance with the updated rules.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
The original transition to mjs introduced some inconsistencies in the linting process. It was important to rectify these issues to maintain code quality and consistency throughout the project.
Does this PR introduce a user-facing change?:
Additional documentation:
Checklist:
Summary by CodeRabbit
Release Notes
New Features
Bug Fixes
Documentation
Refactor
useYorkieDocumenthook for better responsiveness to changes.