-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix Build Error #3362
Fix Build Error #3362
Conversation
WalkthroughThe pull request introduces modifications to the Changes
Suggested reviewers
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
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 (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (5)
Dockerfile (2)
101-101
: Remove debug echo statement from production image.The echo statement for
NEXT_IGNORE_ESLINT_ERROR_ON_BUILD
appears to be for debugging purposes. Consider removing it from the production image to maintain a clean environment and avoid exposing configuration details.-RUN echo "NEXT_IGNORE_ESLINT_ERROR_ON_BUILD: $NEXT_IGNORE_ESLINT_ERROR_ON_BUILD"
Based on the search results, I can generate the final response since I have enough information about the ESLint configuration and usage in the codebase.
ESLint Suppression Strategy Needs Review
The codebase shows extensive use of ESLint disable comments, particularly in the mobile app, indicating systematic bypassing of linting rules rather than addressing underlying issues. Consider:
Most common disabled rules are:
react-native/no-inline-styles
react-native/no-color-literals
no-mixed-spaces-and-tabs
react-hooks/exhaustive-deps
The project has proper ESLint configurations:
- Multiple ESLint plugins configured (
@typescript-eslint
,react
,prettier
, etc.)- Environment-specific configs (web, mobile, server)
- Automated linting in CI/CD (
lint-staged
, pre-commit hooks)Instead of using
NEXT_IGNORE_ESLINT_ERROR_ON_BUILD=true
, recommend:
- Create an
.eslintignore
file for build-specific exclusions- Address the most commonly disabled rules by:
- Extracting inline styles to StyleSheet objects
- Moving color literals to a theme configuration
- Fixing mixed spaces/tabs through Prettier configuration
- Properly handling React hook dependencies
🔗 Analysis chain
Line range hint
21-101
: Security Consideration: Review ESLint Error Suppression StrategyWhile ignoring ESLint errors might fix the build, it could mask potential issues. Consider:
- Addressing the underlying ESLint errors instead of bypassing them
- Making this a temporary solution with a TODO to fix the actual issues
- Only ignoring specific ESLint rules that are causing problems rather than all errors
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for existing ESLint configurations and errors # Look for Next.js specific ESLint config echo "Checking for Next.js ESLint configuration:" rg -A 5 "eslintConfig|eslint" package.json # Check for ESLint errors in build logs if they exist echo "\nChecking for ESLint error patterns in any log files:" fd -e log -e txt | xargs rg "eslint|ESLint"Length of output: 90305
apps/web/app/[locale]/timesheet/[memberId]/page.tsx (2)
Line range hint
38-42
: Simplify dateRange state initializationThe dateRange state initialization can be simplified using a single useMemo to avoid recalculations on re-renders.
-const [dateRange, setDateRange] = React.useState<{ from: Date | null; to: Date | null }>({ - from: startOfDay(new Date()), - to: endOfDay(new Date()) -}); +const [dateRange, setDateRange] = React.useState<{ from: Date | null; to: Date | null }>(() => ({ + from: startOfDay(new Date()), + to: endOfDay(new Date()) +}));
Line range hint
126-139
: Consider debouncing the search inputFor better performance, especially with large datasets, consider debouncing the search input to reduce unnecessary re-renders.
+import { useDebounce } from '@/app/hooks'; <input - onChange={(v) => setSearch(v.target.value)} + onChange={(v) => { + const debouncedSearch = useDebounce(v.target.value, 300); + setSearch(debouncedSearch); + }} role="searchbox" aria-label="Search timesheet" type="search" name="timesheet-search" id="timesheet-search" className="!h-[2.2rem] w-full bg-transparent focus:border-transparent focus:ring-2 focus:ring-transparent placeholder-gray-500 placeholder:font-medium shadow-sm outline-none" placeholder={t('common.SEARCH')} />apps/web/app/hooks/features/useOrganizationTeams.ts (1)
308-309
: Good performance optimization!The memoization of the
members
array prevents unnecessary recalculations whenactiveTeam.members
hasn't changed. This is particularly beneficial in preventing re-renders of child components that depend on this data.Consider adding a similar memoization for
currentUser
to further optimize performance:const members = useMemo(() => activeTeam?.members || [], [activeTeam?.members]); -const currentUser = members.find((member) => member.employee.userId === user?.id); +const currentUser = useMemo( + () => members.find((member) => member.employee.userId === user?.id), + [members, user?.id] +);
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (3)
Dockerfile
(4 hunks)apps/web/app/[locale]/timesheet/[memberId]/page.tsx
(1 hunks)apps/web/app/hooks/features/useOrganizationTeams.ts
(3 hunks)
🔇 Additional comments (3)
Dockerfile (1)
21-21
: 🛠️ Refactor suggestion
Use ARG value and document the purpose of ESLint error handling.
While adding ESLint error handling is good for fixing build issues, consider these improvements:
- Use the ARG value instead of hardcoding:
ARG NEXT_IGNORE_ESLINT_ERROR_ON_BUILD=true
# ... other lines ...
-ENV NEXT_IGNORE_ESLINT_ERROR_ON_BUILD=true
+ENV NEXT_IGNORE_ESLINT_ERROR_ON_BUILD=${NEXT_IGNORE_ESLINT_ERROR_ON_BUILD}
- Add a comment explaining the purpose and implications of this flag.
Also applies to: 84-84
apps/web/app/[locale]/timesheet/[memberId]/page.tsx (1)
Line range hint 190-203
: LGTM! Well-implemented view toggle component
The ViewToggleButton component is well-structured with:
- Proper TypeScript typing
- Clean conditional styling
- Good internationalization support
apps/web/app/hooks/features/useOrganizationTeams.ts (1)
29-29
: LGTM: Import addition aligns with optimization changes
The addition of useMemo
import is appropriate for the performance optimization changes implemented in this file.
…ble `NEXT_IGNORE_ESLINT_ERROR_ON_BUILD`.
Fix Build Error
Please include a summary of the changes and the related issue.
Type of Change
Checklist
Summary by CodeRabbit
New Features
Improvements
Bug Fixes