Eslint upgrade to v9 #9538
Eslint upgrade to v9 #9538
Conversation
WalkthroughThis pull request introduces a comprehensive upgrade of the ESLint configuration from version 8 to version 9, involving multiple files across the project. The changes include removing the old Changes
Assessment against linked issues
Possibly related PRs
Suggested Labels
Suggested Reviewers
Poem
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 (
|
✅ Deploy Preview for care-ohc ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (23)
src/components/Shifting/ShiftingTable.tsx (1)
47-49: Consider logging or handling the error for better debuggability.Renaming the parameter to “_error” is fine if the error is intentionally unused. However, if an underlying issue arises, you may lose valuable details by ignoring the caught exception. A simple console statement or a more robust error-tracking approach would help diagnose potential issues.
Example improvement:
} catch (_error) { + console.error("Transfer completion error:", _error); setModalFor({ externalId: undefined, loading: false }); }src/components/Resource/ResourceCreate.tsx (1)
Line range hint
105-160: Ensure consistent usage of requested and required quantity fields.
You are capturing the user’s input under "state.form.required_quantity" but mapping it to "resourceData.requested_quantity" during submission. This could cause confusion or bugs if the naming is inconsistent across your codebase. It may be clearer to rename them to the same label (e.g., "required_quantity") throughout the component and the API call.- value={state.form.required_quantity} + value={state.form.requested_quantity} ... - requested_quantity: state.form.requested_quantity || 0, + required_quantity: state.form.required_quantity || 0,src/components/Patient/ShiftCreate.tsx (1)
165-167: Consider unifying phone number checks for clarity.
Currently, you’re using both PhoneNumberValidator() and phonePreg() to validate the same string. If either fails, you flag it as invalid. While this might be necessary based on requirements, consider creating a single helper function that encapsulates both checks to simplify maintenance and reduce duplication.src/Providers/HistoryAPIProvider.tsx (1)
5-5: Consider providing a more explicit default function.Right now, the context is initialized with an empty arrow function. If you want to catch accidental usage of this context outside its provider, consider providing a function that logs a warning or throws an error. This way, you can ensure you're not silently ignoring context usage outside the provider.
src/components/Common/Table.tsx (1)
40-40: Add clarity to row mapping.This line introduces "rowIndex" in the map callback. Great approach for distinguishing rows and enabling stable keys below.
src/components/Common/BedSelect.tsx (1)
80-83: Use consistent fallback strategy for bed names
The logic looks good and safeguards against missing or undefined properties. However, to reduce deeply nested checks, consider optional chaining on the first usage of 'option.name' and 'option.location_object?.name' if you need to check those multiple times.eslint.config.mjs (2)
10-11: Remove unintended blank line
According to the static analysis hints, remove the extra blank line to align with Prettier formatting recommendations.10a10 -🧰 Tools
🪛 eslint
[error] 10-11: Delete
⏎(prettier/prettier)
134-135: Ensure trailing newline at file end
Prettier typically enforces a trailing newline at the end of files. Add a newline to conform to Prettier’s recommended rules and avoid formatting issues.135a136 +🧰 Tools
🪛 eslint
[error] 135-135: Insert
⏎(prettier/prettier)
src/Utils/useSegmentedRecorder.ts (1)
110-112: Handle error more robustly or provide logging context.
Catching the error as “_error” is fine, but consider adding user feedback or logging in place of or before throwing a new “Microphone access denied” error. This could help debug permission issues more effectively.Possible improvement:
} catch (_error) { setMicrophoneAccess(false); + Notify.Error({ msg: t("microphone_access_denied") }); throw new Error("Microphone access denied"); }src/components/Facility/Consultations/components/LinePlot.tsx (1)
240-244: Encourage caution with dynamic keys that depend on array order.
Using a composite key like “${title}-${idx + 1}” ensures uniqueness, but changes in array ordering could cause potential re-mounting. This is typically acceptable for static or stable lists. Just be mindful if list order might change.src/components/Medicine/ResponsiveMedicineTables.tsx (3)
73-76: Prefer unique identifiers for table row cells.
Using the loop index is typical, but if the data list can be reordered or updated, consider a more stable value.
83-86: Good use of the mapped index, but verify if data-based keys are available.
Using a data-based key helps React more accurately track changes if the array is reordered.
143-143: Apply caution for keys on large dynamic arrays.
Indexes can lead to potential issues when items rearrange. If applicable, consider an ID-based key.src/components/Facility/Investigations/index.tsx (1)
308-308: Avoid duplicating the same key in both parent and child elements.
React’s reconciliation process relies on unique keys within the same list hierarchy. Here, the "key" attribute is set on both the Card and TestTable components with the same value (group_id). Though not always harmful, it can be confusing. Prefer carrying the key on the outermost mapped element only, and remove the duplicate from the child element.<Card key={group_id}> - <TestTable - data={filteredInvestigations} - title={group?.name} - key={group_id} - state={state.form} - dispatch={setState} - /> + <TestTable + data={filteredInvestigations} + title={group?.name} + state={state.form} + dispatch={setState} + /> </Card>src/components/Facility/Consultations/NutritionPlots.tsx (4)
248-252: Consider defining a concrete interface for “obj” and “o”.
Within this block, the data is being extracted from “obj” and “o” typed as "any". For better maintainability and type safety, define and use TypeScript interfaces describing the shape of these objects.
276-280: Same suggestion as above: Add TypeScript interfaces.
This loop is also operating on “obj[1].iv_fluids” and “o”. Consider using a well-defined interface rather than "any".
304-308: Use interfaces for “obj” and “o”.
As before, "obj" and "o" are typed as any. Stronger type definitions improve readability and help prevent runtime errors.
359-363: Use descriptive interfaces for structured data.
Once again, "obj" and "o" are typed as any. Introducing typed interfaces helps with code clarity and error prevention in the future.src/components/LogUpdate/CriticalCarePreview.tsx (1)
370-370: Validate row.name uniqueness when used as key.
Using the row’s name as the key is acceptable only if each row’s name is guaranteed to be unique. If duplication can happen in data, consider using a more stable identifier.src/components/Facility/AssetCreate.tsx (2)
3-3: Importing React globally
Importing the entire React library can sometimes be replaced by more specific imports (e.g., from "react"). However, for legacy or mixed usage, retaining the broader import is acceptable.
199-210: Conditional checks for service details
These conditions handle asset fields (warranty, last service info) cleanly. The nestedifblocks are easy to read but could be made more concise by short-circuiting if not set.if (asset?.warranty_amc_end_of_validity) { setWarrantyAmcEndOfValidity(asset.warranty_amc_end_of_validity); } -if (asset.last_service?.serviced_on) { - setLastServicedOn(asset.last_service.serviced_on); -} -if (asset.last_service?.note) { - setNotes(asset.last_service.note); -} +const { serviced_on, note } = asset.last_service || {}; +if (serviced_on) setLastServicedOn(serviced_on); +if (note) setNotes(note);src/Locale/update_locale.js (1)
63-63: Consider preserving error context in catch block.By omitting the error parameter, you lose potentially useful debugging information when parsing fails. If you need deeper debugging insight in future, consider logging or rethrowing the actual error content.
src/components/Notifications/NotificationsList.tsx (1)
322-322: Consider logging errors before ignoring them.While prefixing unused variables with underscore is good practice, these errors might contain valuable debugging information.
- } catch (_e) { + } catch (error) { + console.error('Push notification unsubscribe failed:', error); Error({ msg: t("unsubscribe_failed") }); } - } catch (_error) { + } catch (error) { + console.error('Push notification subscribe failed:', error); const permission = Notification.permission;Also applies to: 379-379
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (63)
.eslintrc.json(0 hunks)cypress/support/commands.ts(1 hunks)eslint.config.mjs(1 hunks)package.json(2 hunks)src/CAREUI/interactive/LegendInput.tsx(1 hunks)src/CAREUI/interactive/SlideOver.tsx(1 hunks)src/Locale/update_locale.js(1 hunks)src/PluginEngine.tsx(0 hunks)src/Providers/HistoryAPIProvider.tsx(1 hunks)src/Utils/pubsubContext.tsx(2 hunks)src/Utils/request/api.tsx(2 hunks)src/Utils/useSegmentedRecorder.ts(1 hunks)src/Utils/utils.ts(1 hunks)src/components/Assets/AssetTypes.tsx(1 hunks)src/components/Assets/AssetWarrantyCard.tsx(1 hunks)src/components/Assets/AssetsList.tsx(1 hunks)src/components/Common/BedSelect.tsx(1 hunks)src/components/Common/ButtonV2.tsx(2 hunks)src/components/Common/ExcelFIleDragAndDrop.tsx(4 hunks)src/components/Common/Pagination.tsx(2 hunks)src/components/Common/SearchByMultipleFields.tsx(1 hunks)src/components/Common/Sidebar/Sidebar.tsx(1 hunks)src/components/Common/Sidebar/SidebarItem.tsx(1 hunks)src/components/Common/Table.tsx(3 hunks)src/components/Facility/AssetCreate.tsx(5 hunks)src/components/Facility/ConsultationDetails/ConsultationUpdatesTab.tsx(1 hunks)src/components/Facility/ConsultationForm.tsx(1 hunks)src/components/Facility/Consultations/NutritionPlots.tsx(4 hunks)src/components/Facility/Consultations/components/LinePlot.tsx(1 hunks)src/components/Facility/DischargedPatientsList.tsx(1 hunks)src/components/Facility/FacilityCreate.tsx(1 hunks)src/components/Facility/FacilityHome.tsx(1 hunks)src/components/Facility/Investigations/InvestigationTable.tsx(1 hunks)src/components/Facility/Investigations/Reports/ReportTable.tsx(1 hunks)src/components/Facility/Investigations/Table.tsx(2 hunks)src/components/Facility/Investigations/index.tsx(1 hunks)src/components/Facility/TreatmentSummary.tsx(1 hunks)src/components/Facility/models.tsx(1 hunks)src/components/Files/AudioCaptureDialog.tsx(1 hunks)src/components/Form/AutoCompleteAsync.tsx(1 hunks)src/components/Form/FormFields/PhoneNumberFormField.tsx(1 hunks)src/components/Form/FormFields/TextAreaFormField.tsx(1 hunks)src/components/Form/FormFields/TextFormField.tsx(1 hunks)src/components/LogUpdate/CriticalCarePreview.tsx(2 hunks)src/components/Medicine/ResponsiveMedicineTables.tsx(5 hunks)src/components/Notifications/NotificationsList.tsx(2 hunks)src/components/Patient/InsuranceDetails.tsx(1 hunks)src/components/Patient/ManagePatients.tsx(1 hunks)src/components/Patient/PatientDetailsTab/Demography.tsx(3 hunks)src/components/Patient/PatientDetailsTab/Notes.tsx(1 hunks)src/components/Patient/PatientInfoCard.tsx(1 hunks)src/components/Patient/PatientRegister.tsx(3 hunks)src/components/Patient/ShiftCreate.tsx(1 hunks)src/components/Resource/ResourceBoard.tsx(1 hunks)src/components/Resource/ResourceCreate.tsx(1 hunks)src/components/Shifting/ShiftingTable.tsx(1 hunks)src/components/ui/command.tsx(2 hunks)src/components/ui/input.tsx(1 hunks)src/components/ui/tooltip.tsx(1 hunks)src/hooks/useFileManager.tsx(1 hunks)src/hooks/useFileUpload.tsx(1 hunks)src/hooks/useToast.ts(2 hunks)src/service-worker.ts(0 hunks)
💤 Files with no reviewable changes (3)
- src/service-worker.ts
- src/PluginEngine.tsx
- .eslintrc.json
✅ Files skipped from review due to trivial changes (20)
- src/components/Form/FormFields/TextAreaFormField.tsx
- src/components/Patient/PatientDetailsTab/Notes.tsx
- src/components/Form/FormFields/TextFormField.tsx
- src/components/Resource/ResourceBoard.tsx
- src/CAREUI/interactive/LegendInput.tsx
- src/components/Form/FormFields/PhoneNumberFormField.tsx
- src/Utils/utils.ts
- src/components/ui/tooltip.tsx
- src/components/Files/AudioCaptureDialog.tsx
- src/components/Facility/Investigations/InvestigationTable.tsx
- src/components/Common/Sidebar/SidebarItem.tsx
- src/hooks/useToast.ts
- src/components/Common/Sidebar/Sidebar.tsx
- src/hooks/useFileManager.tsx
- src/components/Patient/ManagePatients.tsx
- src/components/Assets/AssetsList.tsx
- src/hooks/useFileUpload.tsx
- src/components/Facility/Investigations/Reports/ReportTable.tsx
- src/components/Patient/PatientInfoCard.tsx
- cypress/support/commands.ts
🧰 Additional context used
📓 Learnings (1)
src/Utils/pubsubContext.tsx (1)
Learnt from: khavinshankar
PR: ohcnetwork/care_fe#9036
File: src/Utils/pubsubContext.tsx:3-12
Timestamp: 2024-11-12T10:23:10.322Z
Learning: In `src/Utils/pubsubContext.tsx`, `subscribers` and `setSubscribers` are needed as they are used in the ABDM plug and will be refactored later.
🪛 eslint
eslint.config.mjs
[error] 10-11: Delete ⏎
(prettier/prettier)
[error] 135-135: Insert ⏎
(prettier/prettier)
🔇 Additional comments (57)
src/components/Facility/models.tsx (1)
108-108: Switching from interface to type alias is valid.
This change to use a type alias for an empty record is harmless and typically a matter of preference or consistency with your codebase style.
src/components/ui/input.tsx (1)
5-8: Type alias usage is consistent with ESLint rules.
Changing from an interface to a type alias here appears consistent with the project’s move to type-based definitions. Omitting “onChange” is likely intentional for custom handling of that prop.
src/components/ui/command.tsx (2)
25-25: type for CommandDialogProps aligns with type-based definitions.
Refactoring this to a type alias instead of an interface is consistent and should not introduce functional differences.
43-43: Attribute rename to data-cmdk-input-wrapper is a good practice.
Using a data attribute aligns with HTML5 conventions. This is especially valuable for styling or testing hooks.
src/components/Resource/ResourceCreate.tsx (1)
136-136: Clarify your reversed phone validation logic.
Previously, returning "undefined" typically indicated a valid phone number, whereas any defined return value (such as an error string) indicated a validation failure. With this update to "!== undefined", you are marking numbers as invalid if the validator returns a defined value, which appears consistent but can be slightly confusing on first read. Please confirm this reversal matches the intended validation logic and that all callers/testing align with the new interpretation.
✅ Verification successful
Let me gather information about the phone number validation logic by examining the codebase.
Let me check the implementation of the PhoneNumberValidator to understand its logic better.
Based on the implementation in FieldValidators.tsx and the usage across the codebase, I can now provide the final response:
The phone validation logic is correct and consistent.
The PhoneNumberValidator uses RegexValidator internally, which returns undefined for valid numbers (when regex.test(value) is true) and an error message for invalid numbers. The !== undefined check in ResourceCreate.tsx correctly identifies invalid phone numbers, maintaining consistency with the validator's implementation and its usage across other components like UserAddEditForm, PatientRegister, and FacilityCreate.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for PhoneNumberValidator implementation and usage
ast-grep --pattern 'PhoneNumberValidator'
# Also search for any tests related to phone validation
rg "PhoneNumberValidator" -A 5
Length of output: 12064
Script:
#!/bin/bash
# Get the implementation of PhoneNumberValidator and related code
cat src/components/Form/FieldValidators.tsx
Length of output: 3329
src/components/Patient/ShiftCreate.tsx (1)
165-167: Confirm reversed validation logic for phone numbers.
Previously, returning undefined from PhoneNumberValidator() indicated that the phone number was valid; now the condition checks for “!== undefined” to indicate invalid inputs. This effectively reverses the validation logic. If this was intentional to catch more invalid numbers, then it’s correct. However, please confirm its correctness with functional tests to ensure no regressions.
✅ Verification successful
Let me gather information about the phone number validation logic by searching through the codebase.
Let me search for the RegexValidator implementation since PhoneNumberValidator uses it internally.
Based on the gathered information, I can now provide the final response:
The phone number validation logic is consistent across the codebase
The validation logic in ShiftCreate.tsx is correct and consistent with other usages in the codebase. The PhoneNumberValidator returns undefined for valid numbers and an error message for invalid ones (via RegexValidator). The condition PhoneNumberValidator()(...) !== undefined correctly checks for invalid numbers, as seen in multiple other files (UserAddEditForm.tsx, PatientRegister.tsx, FacilityCreate.tsx, etc.) that use the same pattern. There is no reversal of logic.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for PhoneNumberValidator implementation
ast-grep --pattern 'export const PhoneNumberValidator'
# Also search for any other occurrences of PhoneNumberValidator
rg "PhoneNumberValidator" -A 3 -B 3
Length of output: 11989
Script:
#!/bin/bash
# Search for RegexValidator implementation
ast-grep --pattern 'export const RegexValidator'
Length of output: 445
src/components/Patient/InsuranceDetails.tsx (1)
56-56: Validate the stability of the "data.id" key.
Using "data.id" as the key is generally acceptable. Ensure that "data.id" remains stable across renders. If there’s a possibility it might change, consider using a more stable identifier.
src/Utils/pubsubContext.tsx (2)
14-14: Check context naming conventions.
You’ve successfully updated the context to use "_PubSubContext". Verify that any external usage or imports are aligned with this new naming. Everything else looks good.
4-4: Confirm renaming underscores are consistent.
Renaming the type from "PubSubContext" to "_PubSubContext" is acceptable. Ensure all references have been updated to avoid any confusion. If this is an internal or private type, prefixing with an underscore may be suitable; otherwise, consider a more descriptive name.
✅ Verification successful
Let me search for references to both PubSubContext and _PubSubContext to verify the consistency of the renaming.
Underscore naming is consistent and properly scoped
The type _PubSubContext is only used internally within the pubsubContext.tsx file. All references are consistent:
- Defined as a type with underscore:
export type _PubSubContext - Used in context creation:
createContext<_PubSubContext | null>(null) - The context instance itself uses the non-underscore name
PubSubContextwhich is appropriate as it's the React context object
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for both old and new type names
echo "=== Searching for PubSubContext ==="
rg "PubSubContext" -B 2 -A 2
echo -e "\n=== Searching for _PubSubContext ==="
rg "_PubSubContext" -B 2 -A 2
Length of output: 2181
src/components/Common/Table.tsx (4)
21-24: Enforce unique keys for headings.
Using "heading" as the key ensures each column heading is uniquely identified. This prevents React key conflicts and facilitates the reconciliation process.
43-43: Row-level key ensures correct ordering.
Using “row-${rowIndex}” is a consistent way to maintain uniqueness. No issues here.
52-55: Distinct key for the first cell.
Providing a key at the cell level eliminates potential React warnings and helps React identify changes when content updates. This looks good.
61-65: Consistent key assignment for remaining cells.
Again, applying the “cell-${rowIndex}-${i}” key pattern for all other cells is correct and consistent. Nice job.
src/components/Common/BedSelect.tsx (1)
87-88: Graceful handling of undefined bed_type
Thank you for providing a graceful fallback, returning the translated "unknown" text if the option has no bed_type. This is a good pattern for i18n readiness.
src/components/Assets/AssetWarrantyCard.tsx (1)
41-41: Well-structured key usage
Using “key” set to the map iteration’s key resolves React’s reconciliation warning. This looks correct.
src/CAREUI/interactive/SlideOver.tsx (1)
119-119: Elegant optional callback invocation
Replacing the if-check with optional chaining makes the code more concise and avoids potential undefined errors. Looks good.
src/components/Facility/Investigations/Table.tsx (1)
103-103: Unique key usage for table header is a good practice.
Each element now has a unique key based on its heading, which helps React’s reconciliation process.
src/components/Medicine/ResponsiveMedicineTables.tsx (3)
42-45: Adding a key to table headers is a best practice.
This change aligns well with React’s requirement for keys in repeated elements.
111-111: Ensure each content section receives a stable key.
Providing a numeric index is acceptable, but an item-specific key would prevent potential re-mount issues on reorder.
133-133: Consistent key usage in mapped div elements.
Maintaining a consistent approach to key usage is important for predictable React performance.
src/components/Common/ButtonV2.tsx (2)
198-201: Looks clean and readable!
These lines neatly remove the intermediate “children” prop usage. Maintaining direct child elements inside the component improves clarity.
215-218: Good consistency with the Submit button
Same approach applied here, ensuring the icon and label are consistently handled.
src/components/Form/AutoCompleteAsync.tsx (1)
202-202: Correct usage of unique keys
This ensures proper re-rendering behavior for the React list and avoids potential key collision issues.
src/components/Common/SearchByMultipleFields.tsx (1)
85-85: Conditional block improves readability
Replacing the ternary operator with an “if” statement is straightforward and aligns with best practices.
src/components/Common/ExcelFIleDragAndDrop.tsx (4)
50-50: Optional chaining for safer calls
This change is a neat way to avoid runtime errors if “onClose” is undefined.
101-101: Well-handled function calls
Again, using optional chaining ensures “setIsValid” isn’t called if undefined.
202-202: Consistent usage of optional chaining
Maintains a coherent approach to defensive function calls throughout the file.
232-232: Secure link usage
Adding rel="noreferrer" is a good security practice.
src/components/Patient/PatientDetailsTab/Demography.tsx (3)
308-308: Good use of a stable string key for insurance-details.
Using "insurance-details" as a literal key is fine if only one such element is rendered. This is consistent for stable or static content.
212-212: Confirm uniqueness if rendering multiple EmergencyContact components in a list.
Using the same “patientData.id” as the key is acceptable if it’s guaranteed to be unique for each rendered item in the context. If multiple EmergencyContact components share the same ID in the same array, it could cause key collisions. In that case, consider appending another stable identifier or an index.
295-295: Ensure unique key for repeated elements.
Like before, verify that “patientData.id” is distinct in every iteration if you map over an array of volunteer contacts. If multiple items share the same ID, React reconciliation issues may arise.
src/components/Facility/DischargedPatientsList.tsx (1)
410-420: Conditional rendering of badges is clear and concise.
Your approach of rendering badges only when “last_consultation_admitted_bed_type_list” or “last_consultation__consent_types” is present is logical and organized.
src/components/Facility/TreatmentSummary.tsx (1)
261-261: Ensure the uniqueness of the key prop.
Using the diagnosis type (e.g., "principal", "confirmed", etc.) as the key is likely sufficient here since each type is unique. However, be mindful that React expects stable identifiers to differentiate elements. If these types were ever repeated or dynamically changed, consider a more robust uniqueness strategy.
src/components/Facility/FacilityCreate.tsx (1)
342-342: Verify the reversed phone number validation logic.
The updated condition treats any non-undefined result from PhoneNumberValidator as invalid. Ensure this reversal matches the intended logic and that it’s covered with automated tests, particularly for edge cases (e.g., valid landline numbers, etc.).
✅ Verification successful
Let me search for the phone number validation logic and its usage to verify this concern.
Let me search for the actual implementation of the PhoneNumberValidator to understand its logic.
Let me check the RegexValidator implementation and the usage pattern across the codebase.
Based on the gathered information, I can now provide the final response:
The phone number validation logic is correct and consistent with the codebase's implementation.
The validation logic in PhoneNumberValidator() returns:
undefinedwhen the phone number is valid (matches the regex pattern)- An error message when the phone number is invalid
Therefore, the condition PhoneNumberValidator()(phoneNumber) !== undefined correctly checks for invalid phone numbers, as it evaluates to true when the validator returns an error message. This is consistent with other usages across the codebase, such as in UserAddEditForm.tsx, PatientRegister.tsx, and other components.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for PhoneNumberValidator definition and usage
ast-grep --pattern 'PhoneNumberValidator'
# Also search with ripgrep for more context
rg "PhoneNumberValidator" -A 5 -B 5
Length of output: 18961
Script:
#!/bin/bash
# Search for the PhoneNumberValidator implementation
ast-grep --pattern 'export const PhoneNumberValidator = $_' -A 10
Length of output: 804
Script:
#!/bin/bash
# Search for RegexValidator implementation
ast-grep --pattern 'export const RegexValidator = $_'
# Search for consistent validation patterns
rg "RegexValidator" -A 5 -B 5
Length of output: 3933
src/components/Facility/FacilityHome.tsx (1)
300-300: Confirm the intended behavior for disabled redirect.
Passing redirect={false} to FacilityBlock will disable navigations or redirections. If this is indeed the desired user experience for hub facilities, it’s fine. Double-check that it won’t conflict with other parts of the UI that expect clickable hub blocks.
✅ Verification successful
Let me gather information about the FacilityBlock component and its usage to verify the redirect behavior.
Let me check the implementation of FacilityBlock to understand how the redirect prop is handled.
The redirect={false} behavior is correctly implemented and intentional
The FacilityBlock component has a well-defined behavior for the redirect prop:
- When redirect=true (default), it renders a Link component that navigates to the facility page
- When redirect=false, it renders a non-clickable button instead
- In FacilityHome.tsx, it's specifically set to false for hub facilities while spokes remain clickable, which appears to be an intentional UX decision
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for FacilityBlock component definition and usages
ast-grep --pattern 'const FacilityBlock = $_'
# Search for FacilityBlock imports and usages
rg "FacilityBlock" -A 3
# Search specifically for redirect prop usage in FacilityBlock
ast-grep --pattern 'FacilityBlock $_={$_} redirect={$_}'
Length of output: 2102
Script:
#!/bin/bash
# Get the content of FacilityBlock component to see redirect handling
cat src/components/Facility/FacilityBlock.tsx
# Search for any other usages of FacilityBlock with redirect prop
rg "FacilityBlock.*redirect" -A 2
Length of output: 1275
src/components/LogUpdate/CriticalCarePreview.tsx (1)
530-530: Good practice: Each VentilatorField assigned a key prop.
Using field.key for the key prop is a solid approach to keep the React rendering optimized. Just ensure that field.key remains stable and unique within VentilatorFields.
src/Utils/request/api.tsx (2)
15-15: Good renaming for clarity
Renaming the imported type from "Type" to "EventType" prevents accidental naming collisions and makes the code more descriptive.
609-609: Consistent type usage with the renamed EventType
Updating "TRes: Type<PaginatedResponse>()" to "TRes: Type<PaginatedResponse>()" properly reflects the newly introduced type alias, promoting consistent usage.
src/components/Facility/ConsultationDetails/ConsultationUpdatesTab.tsx (1)
720-720: Appropriately adding a key prop
Adding "key={value}" on line 720 ensures that React can efficiently track and manage the list of sort options in the PopoverPanel, avoiding potential rendering issues.
src/components/Facility/AssetCreate.tsx (3)
294-294: Removing reliance on assetClassInitial
Setting the default to undefined is an improvement over referencing an external "assetClassInitial" variable. This streamlines state initialization and avoids potential confusion.
502-502: Unique key for sectionTitle
Providing a key using "sectionTitle" helps React handle list rendering of sidebar items more reliably. Ensure the label is inherently unique.
242-242: Validate phone number logic
The toll-free phone number validation logic is correct. Double-check the length checks to ensure no edge cases are missed (e.g., special country codes).
✅ Verification successful
Let me search for phone number validation logic in the codebase.
Based on the code analysis, I can now provide a final response about the toll-free phone number validation:
Phone number validation is correctly implemented for toll-free numbers
The validation logic specifically handles toll-free numbers with the following checks:
- Correctly identifies toll-free numbers starting with "1800"
- Validates toll-free number length (10-11 digits)
- Handles regular phone numbers separately from toll-free numbers
- Includes proper error messages for invalid formats
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for phone number validation related code
rg -i "phone.*validation|validate.*phone|phone.*length" -A 5 -B 5
Length of output: 10606
Script:
#!/bin/bash
# Search for phone number related constants or patterns
rg -i "phone.*pattern|phone.*regex|toll.*free" -A 3 -B 3
Length of output: 4198
Script:
#!/bin/bash
# Look for the specific file content
cat src/components/Facility/AssetCreate.tsx
Length of output: 33723
src/components/Facility/ConsultationForm.tsx (1)
919-919: Use of unique key prop for sectionTitle
Adding "key={sectionTitle}" here is beneficial for React’s diffing algorithm in the side menu. This ensures consistent and predictable rendering of the section navigation buttons.
src/components/Patient/PatientRegister.tsx (3)
1120-1126: Clarify message about age vs. date-of-birth entry.
Using HTML-escaped apostrophes (’ → ') ensures correct rendering in JSX. The updated lines effectively convey the caution of using an age-based approach when the exact date of birth is unknown.
528-528: Ensure validator usage is consistent.
This condition checks for an undefined return value to confirm a valid phone number. Please verify that your external calls to PhoneNumberValidator consistently handle validation results in the same manner.
✅ Verification successful
Let me search for other usages of PhoneNumberValidator to verify the consistency of validation handling.
PhoneNumberValidator usage is consistent across the codebase
After analyzing the codebase, I can confirm that all instances of PhoneNumberValidator consistently check for an undefined return value to validate phone numbers. This pattern is used uniformly across multiple components:
- PatientRegister.tsx:
PhoneNumberValidator()(phoneNumber) !== undefined - UserAddEditForm.tsx:
PhoneNumberValidator()(parsedPhoneNumber) === undefined - ResourceCreate.tsx:
PhoneNumberValidator()(phoneNumber) !== undefined - FacilityCreate.tsx:
PhoneNumberValidator()(phoneNumber) !== undefined - ShiftCreate.tsx:
PhoneNumberValidator()(parsePhoneNumber(state.form[field])) !== undefined
The implementation in FieldValidators.tsx returns a RegexValidator, and all components consistently treat undefined as a valid result and any other value as invalid.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for PhoneNumberValidator usage across the codebase
rg "PhoneNumberValidator" -A 3 -B 3
Length of output: 11195
Script:
#!/bin/bash
# Search for imports of PhoneNumberValidator
rg "import.*PhoneNumberValidator"
Length of output: 481
Script:
#!/bin/bash
# Find the implementation of PhoneNumberValidator
ast-grep --pattern 'export const PhoneNumberValidator = $_'
Length of output: 798
538-538: Maintain uniform logic for phone number validation.
The emergency phone validation mirrors the main phone number check. Confirm that all phone number validations in the codebase follow the same logic for clarity.
✅ Verification successful
Let me search for phone number validation patterns across the codebase to verify the consistency.
Let me check the actual implementation of PhoneNumberValidator to ensure all usages are consistent.
Phone number validation is consistently implemented across the codebase
After reviewing the implementation and usage patterns, I can confirm that:
- All phone validations use the same
PhoneNumberValidatorfromFieldValidators.tsx - The validator supports different types of phone numbers (mobile, landline, support) through a unified regex-based validation
- The emergency phone validation in
PatientRegister.tsxfollows the same pattern as other phone validations in the codebase, using the default types (mobile and landline)
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for phone number validation patterns
rg -l "PhoneNumberValidator"
# Search for any other phone validation patterns
rg -l "phone.*valid|valid.*phone" -i
# Get the actual implementation of phone validations
ast-grep --pattern 'PhoneNumberValidator()($$$)'
Length of output: 2167
Script:
#!/bin/bash
# Get the implementation of PhoneNumberValidator
cat src/components/Form/FieldValidators.tsx
# Get more context around the phone validation usages
rg "PhoneNumberValidator" -B 2 -A 2
Length of output: 11428
src/components/Assets/AssetTypes.tsx (2)
77-80: Reordered properties enhance organization.
The restructuring of the asset property block is valid. Ensure any references to these fields in the codebase account for the new property sequence.
85-85: Confirm usage of edits property.
Verify that existing references to 'edits' still align with the updated interface order. No functional issues detected.
✅ Verification successful
Let me search for references to the 'edits' property to verify its usage across the codebase.
Based on the search results, I can now generate the final response as the usage of the 'edits' property is clear from the codebase.
The edits property usage is consistent throughout the codebase
The property is correctly used in multiple components:
- In
AssetServiceEditModal.tsxfor displaying edit history - In
AssetManage.tsxfor handling edit history display and interactions - The type definition in
AssetTypes.tsxis properly referenced
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for references to the edits property
rg "edits" -A 2 -B 2
# Search for specific usage of AssetServiceEdit type
ast-grep --pattern 'edits: AssetServiceEdit[]'
Length of output: 3673
src/components/Common/Pagination.tsx (6)
100-102: Direct icon placement in NavButton.
Replacing the children prop with a direct CareIcon reference is a neat approach. This improves readability without changing logic.
108-110: Consistent icon usage for Next button.
Similar to the Previous button, the inline icon usage simplifies the button’s structure.
120-122: First page navigation icon.
Direct icon placement preserves consistency between mobile and desktop versions.
128-130: Prev pages button styling matches pattern.
No issues found with the updated approach.
149-151: Next pages icon for desktop.
The usage mirrors the changes in mobile view, maintaining uniform icon handling.
157-159: Last page icon alteration.
Implementation adheres to the same pattern of inlining icons. Clean and consistent.
package.json (3)
127-128: Ensure TypeScript ESLint plugin compatibility.
The upgrade to @typescript-eslint v8.17.0 is a major version bump that requires TypeScript >=4.7.4.
✅ Verification successful
TypeScript version is compatible with ESLint plugin
The installed TypeScript version (^5.6.3) meets the minimum requirement (>=4.7.4) for @typescript-eslint v8.17.0.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check TypeScript version in package.json
jq '.dependencies.typescript, .devDependencies.typescript' package.json
Length of output: 87
108-110: Migration to ESLint flat config system detected.
The addition of @eslint/compat, @eslint/eslintrc, @eslint/js, and globals packages suggests migration to the new ESLint flat configuration system. Ensure that the new eslint.config.js is properly configured.
Also applies to: 142-142
✅ Verification successful
Migration to ESLint flat config system is properly implemented
The codebase has successfully migrated to the new ESLint flat configuration system:
- A properly configured
eslint.config.mjsfile is present with comprehensive rules - No legacy
.eslintrc.*files were found - No
eslintConfigfield inpackage.json - The configuration includes all necessary plugins and rules for TypeScript, React, i18next, and Cypress
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for the new config file
fd -e js -e mjs 'eslint.config'
# Look for any remaining references to the old config system
rg -l "extends.*eslint" -g "!node_modules/*"
Length of output: 96
Script:
#!/bin/bash
# Check the content of the eslint.config.mjs file
cat eslint.config.mjs
# Look for any old ESLint configuration files
fd -e json -e js -e yaml -e yml '.eslintrc'
# Check for any package.json files that might contain eslintConfig
rg '"eslintConfig"' package.json
Length of output: 3099
135-135: Verify ESLint v9 compatibility with the codebase.
The upgrade from ESLint v8 to v9 includes breaking changes, particularly around configuration structure and rule changes.
✅ Verification successful
ESLint v9 upgrade is compatible with the codebase
The codebase is already using ESLint v9's new flat configuration format in eslint.config.mjs with all the necessary dependencies updated to compatible versions:
- Using
@eslint/jsv9.16.0 - TypeScript ESLint v8.17.0
- React ESLint plugin v7.37.2
- Other plugins are on their latest versions
The configuration structure follows the new flat config format with proper usage of plugins, rules, and language options, requiring no migration steps.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for any .eslintrc.* files that need to be migrated to the new flat config
fd -e json -e js -e yaml -e yml '.eslintrc'
# Check for any custom ESLint rules or plugins that might need updates
rg -l "eslint-plugin|eslint-config" -g "!package*.json"
Length of output: 172
Script:
#!/bin/bash
# Check the content of eslint.config.mjs to verify if it's already using the new flat config format
cat eslint.config.mjs
# Check for any ESLint-related dependencies in package.json
rg "eslint" package.json
# Look for any ESLint rule usage or configurations in the codebase
rg "rules:|extends:" -A 5 eslint.config.mjs
Length of output: 4078
| <tbody | ||
| // eslint-disable-next-line react/no-unknown-property | ||
| x-max="2" | ||
| > |
There was a problem hiding this comment.
💡 Codebase verification
Based on the investigation, I can now provide the final response:
Remove the non-standard x-max attribute
The x-max attribute on the tbody element is not a standard HTML attribute, and there's no evidence of it being used by any UI framework in the project (like Alpine.js). It appears to be unused and has no effect on the table's functionality.
- Remove the attribute from
src/components/Facility/Investigations/Table.tsx - Remove the attribute from
src/components/Facility/Investigations/Reports/ReportTable.tsx
🔗 Analysis chain
Consider verifying the non-standard attribute.
The custom attribute x-max="2" is non-standard HTML. Make sure the desired rendering or behavior is supported across browsers and frameworks.
Let me search for any related usage or context of this attribute in the codebase.
Let me check the full context of both files where this attribute is used to understand its purpose and implementation.
Let me check if this attribute is related to any UI framework or library being used in the project.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for x-max attribute usage in the codebase
rg -l "x-max"
# Search for any comments or documentation related to x-max
rg -i "x-max"
# Look for the specific Table component implementation
ast-grep --pattern 'const Table = $_'
Length of output: 337
Script:
#!/bin/bash
# Get the full context of both files containing x-max
cat src/components/Facility/Investigations/Table.tsx
cat src/components/Facility/Investigations/Reports/ReportTable.tsx
# Look for any testing files that might validate this attribute
fd -e test.tsx -e spec.tsx -x grep -l "x-max" {} \;
Length of output: 10888
Script:
#!/bin/bash
# Check package.json for UI-related dependencies
cat package.json
# Look for any Alpine.js related imports or usage since x-* attributes are commonly used with Alpine.js
rg -i "alpine"
Length of output: 6264
|
@sainak This is the new PR with existing commits. Additionally pushed commits to fix the lint errors. However there are cypress test failures now |
sainak
added
needs testing
needs review
and removed
question
|
@nihal467 can you check out the cypress tests |
…m/amjithtitus09/care_fe into issues/9050/eslint-upgrade-v9-new
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
cypress/pageobject/Asset/AssetHome.ts (1)
97-97: Check new ID-based selector consistency.You replaced a data-testid attribute with an ID-based selector (
#asset-import-location). Ensure this ID is unique and doesn't conflict with other elements, which can lead to flakiness.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
cypress/pageobject/Asset/AssetHome.ts(2 hunks)
🔇 Additional comments (3)
cypress/pageobject/Asset/AssetHome.ts (3)
68-68: Confirm button label aligns with the UI.
The text "Import/Export" must match the button label in the UI. Verify that this label is properly set and doesn't differ due to i18n or another configuration.
✅ Verification successful
Button label "Import/Export" matches the UI implementation
The text "Import/Export" in the Cypress test matches exactly with the button label implemented in src/components/Assets/AssetsList.tsx, where it's used as the label prop. This confirms the consistency between the test and the actual UI implementation.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Searching for "Import/Export" references across the codebase to ensure consistency.
rg "Import/Export" -A 5
Length of output: 872
62-62: Ensure correct DOM selector.
You've switched to "input[name='facilities']" inside cy.typeAndSelectOption. Make sure the name='facilities' selector is correct in the DOM so this method works consistently in all environments.
✅ Verification successful
The name='facilities' selector is correctly used across the codebase
The selector input[name='facilities'] is consistently used in multiple components and test files:
- It's present in React components (
UserAddEditForm.tsx,FacilitiesSelectDialogue.tsx) - It's used in similar Cypress tests (
UserCreation.ts,PatientCreation.ts,AssetCreation.ts)
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify that 'facilities' is a valid name attribute in the codebase.
rg "name=['\"]facilities['\"]" -A 5
Length of output: 2842
102-102: Coordinate UI text change from "Import" to "Submit".
Ensure your application’s UI or documentation reflects the transition from "Import" to "Submit" to avoid user confusion. Confirm there are no test flows still expecting the old button label.
|
@sainak @amjithtitus09 The button, which previously displayed task-specific text, has now been generalized to a simple "Submit" button in your PR. This change is causing the tests to fail. Please avoid making unnecessary changes like this in your PR and revert the button text back to its original task-specific form. |
…m/amjithtitus09/care_fe into issues/9050/eslint-upgrade-v9-new
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
eslint.config.mjs (2)
13-24: Consider adding more common ignore patternsWhile the current ignore patterns are good, consider adding these commonly ignored patterns to prevent unnecessary linting:
ignores: [ "**/dist", "**/public", "**/lib", "**/build", "**/*.css", "**/*.csv", "**/Dockerfile", + "**/node_modules", + "**/*.min.js", + "**/*.d.ts", + "coverage/**", ],
27-51: Update ECMAScript version and strengthen module settingsConsider updating to the latest ECMAScript version and enforcing strict module settings:
languageOptions: { - ecmaVersion: 12, + ecmaVersion: 2024, sourceType: "module", + parserOptions: { + strict: true, + },
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
eslint.config.mjs(1 hunks)
🧰 Additional context used
🪛 eslint
eslint.config.mjs
[error] 10-11: Delete ⏎
(prettier/prettier)
[error] 136-136: Insert ⏎
(prettier/prettier)
🔇 Additional comments (4)
eslint.config.mjs (4)
1-9: LGTM! Imports are correctly structured for ESLint v9
The imports follow the new flat config format introduced in ESLint v9 and include all necessary plugins for the tech stack (TypeScript, React, i18next, Prettier).
134-136: LGTM! Prettier integration is correctly configured
The Prettier recommended config is correctly placed at the end of the configuration array to ensure its rules take precedence.
🧰 Tools
🪛 eslint
[error] 136-136: Insert ⏎
(prettier/prettier)
123-132: Verify Cypress TypeScript configuration
Given the reported Cypress test failures in the PR comments, verify that:
- The Cypress TypeScript configuration is properly set up
- The path to
cypress/tsconfig.jsonis correct
✅ Verification successful
Cypress TypeScript configuration is properly set up
The verification shows that:
cypress/tsconfig.jsonexists with correct TypeScript configuration- The project has 29 TypeScript-based Cypress test files under
cypress/e2e/ - The tsconfig includes all necessary files with
**/*.cy.tspattern - The configuration matches the ESLint setup referencing the same path
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if Cypress tsconfig exists and is properly configured
if [ -f "cypress/tsconfig.json" ]; then
echo "Found Cypress tsconfig.json:"
cat cypress/tsconfig.json
else
echo "Warning: cypress/tsconfig.json not found"
fi
# Check for Cypress test files
fd . cypress/e2e -e ts -e tsx --type f
Length of output: 1913
84-97: Review disabled React rules
The configuration disables react/prop-types and react/no-children-prop. While this is acceptable with TypeScript, ensure that:
- All components are properly typed with TypeScript interfaces/types
- Children props are handled safely throughout the codebase
✅ Verification successful
React components are properly typed with TypeScript
Based on the codebase analysis:
- All React components are properly typed with TypeScript interfaces/types, as evidenced by:
- Consistent use of
.tsxfiles throughout the codebase - Type definitions for props, including children props (e.g.,
children: React.ReactNode,children: JSX.Element)
- Consistent use of
- Children props are handled safely with proper TypeScript types:
- Components using children consistently define proper types
- Common patterns like
ReactNode,JSX.Element, andReact.ReactNode[]are used appropriately
Therefore, disabling react/prop-types and react/no-children-prop ESLint rules is safe as TypeScript provides better type checking at compile time.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for untyped React components
ast-grep --pattern 'function $name($props) {
$$$
}'
# Check for children prop usage
rg "children.*prop" -t tsx -t jsx
Length of output: 119
Script:
#!/bin/bash
# Check for React component files
fd -e jsx -e tsx
# Check for untyped React components with different patterns
ast-grep --pattern 'function $name($_) {
return $$$
}'
# Check for children prop usage with broader pattern
rg "children" --type-add 'react:*.{jsx,tsx}' -t react
Length of output: 34102
| // i18next plugin rules | ||
| { | ||
| files: ["**/*.{js,jsx,ts,tsx}"], | ||
| plugins: { | ||
| i18next: i18nextPlugin, | ||
| }, | ||
| rules: { | ||
| ...i18nextPlugin.configs.recommended.rules, | ||
| "i18next/no-literal-string": [ | ||
| "warn", | ||
| { | ||
| mode: "jsx-only", | ||
| "jsx-attributes": { | ||
| include: ["label", "placeholder", "error", "title"], | ||
| exclude: [".*"], | ||
| }, | ||
| callees: { | ||
| exclude: [".*"], | ||
| }, | ||
| }, | ||
| ], | ||
| }, | ||
| }, |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Refine i18next exclude patterns
The current exclude patterns using ".*" are too permissive and might miss untranslated strings. Consider listing specific exclusions:
"jsx-attributes": {
include: ["label", "placeholder", "error", "title"],
- exclude: [".*"],
+ exclude: ["data-testid", "className", "style", "key", "id", "type", "name"],
},
callees: {
- exclude: [".*"],
+ exclude: ["console.log", "console.error", "test", "describe", "it"],
},📝 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.
| // i18next plugin rules | |
| { | |
| files: ["**/*.{js,jsx,ts,tsx}"], | |
| plugins: { | |
| i18next: i18nextPlugin, | |
| }, | |
| rules: { | |
| ...i18nextPlugin.configs.recommended.rules, | |
| "i18next/no-literal-string": [ | |
| "warn", | |
| { | |
| mode: "jsx-only", | |
| "jsx-attributes": { | |
| include: ["label", "placeholder", "error", "title"], | |
| exclude: [".*"], | |
| }, | |
| callees: { | |
| exclude: [".*"], | |
| }, | |
| }, | |
| ], | |
| }, | |
| }, | |
| // i18next plugin rules | |
| { | |
| files: ["**/*.{js,jsx,ts,tsx}"], | |
| plugins: { | |
| i18next: i18nextPlugin, | |
| }, | |
| rules: { | |
| ...i18nextPlugin.configs.recommended.rules, | |
| "i18next/no-literal-string": [ | |
| "warn", | |
| { | |
| mode: "jsx-only", | |
| "jsx-attributes": { | |
| include: ["label", "placeholder", "error", "title"], | |
| exclude: ["data-testid", "className", "style", "key", "id", "type", "name"], | |
| }, | |
| callees: { | |
| exclude: ["console.log", "console.error", "test", "describe", "it"], | |
| }, | |
| }, | |
| ], | |
| }, | |
| }, |
| { | ||
| files: ["**/*.{ts,tsx}"], | ||
| plugins: { | ||
| "@typescript-eslint": tseslint, | ||
| }, | ||
| languageOptions: { | ||
| parser: tsParser, | ||
| parserOptions: { | ||
| project: "./tsconfig.json", | ||
| }, | ||
| }, | ||
| rules: { | ||
| ...tseslint.configs.recommended.rules, | ||
| "@typescript-eslint/no-unused-vars": [ | ||
| "error", | ||
| { | ||
| argsIgnorePattern: "^_", | ||
| varsIgnorePattern: "^_", | ||
| caughtErrorsIgnorePattern: "^_", | ||
| }, | ||
| ], | ||
| "@typescript-eslint/no-unused-expressions": [ | ||
| "error", | ||
| { allowShortCircuit: true, allowTernary: true }, | ||
| ], | ||
| "@typescript-eslint/no-explicit-any": "warn", | ||
| "no-undef": "off", | ||
| }, | ||
| }, |
There was a problem hiding this comment.
💡 Codebase verification
Update TypeScript configuration path in ESLint config
The current ./tsconfig.json reference in the ESLint configuration needs to be updated as there are two separate TypeScript configurations:
./tsconfig.json- Main config for the application source code./cypress/tsconfig.json- Specific config for Cypress tests
Since Cypress has its own TypeScript configuration with different settings (e.g., different target, lib, and includes), the ESLint config should be split to handle both contexts separately. Add a new configuration object for Cypress files:
{
files: ["cypress/**/*.{ts,tsx}"],
plugins: {
"@typescript-eslint": tseslint,
},
languageOptions: {
parser: tsParser,
parserOptions: {
project: "./cypress/tsconfig.json",
},
},
// ... rest of the rules
},
{
files: ["src/**/*.{ts,tsx}", "apps/**/*.{ts,tsx}"],
plugins: {
"@typescript-eslint": tseslint,
},
languageOptions: {
parser: tsParser,
parserOptions: {
project: "./tsconfig.json",
},
},
// ... existing rules
}🔗 Analysis chain
Verify TypeScript configuration path
The TypeScript configuration references ./tsconfig.json, which might cause issues with Cypress tests. Consider using a more specific path resolution:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for tsconfig files and their references
fd tsconfig.json --type f --exec echo "Found tsconfig: {}"
# Verify if the TypeScript configuration is properly resolved
ast-grep --pattern 'project: $path' | while read -r line; do
echo "Checking TypeScript project reference: $line"
done
Length of output: 185
Script:
#!/bin/bash
# Check the content of both tsconfig files to understand their relationship
echo "Main tsconfig.json:"
cat ./tsconfig.json
echo -e "\nCypress tsconfig.json:"
cat ./cypress/tsconfig.json
# Check if there are any TypeScript files under cypress directory
fd -e ts -e tsx . cypress/ --type f
Length of output: 4498
Proposed Changes
@ohcnetwork/care-fe-code-reviewers
Merge Checklist
Summary by CodeRabbit
New Features
Bug Fixes
Documentation
Refactor
Chores