[Enhancement] Consider making ESLint configuration stricter
Author: Leong-Qi-JinCreated Aug 25, 2026Updated Aug 25, 2026
At the moment, the map.tsx is violating a significant number of ESLint rules in my project. I understand some of these are unavoidable (many are probably acceptable with an eslint-disable), but it would be great if some of the following rules which are violated are fixed.
- @typescript-eslint/no-non-null-assertion
- @typescript-eslint/no-unsafe-type-assertion
- @typescript-eslint/no-misused-promises
- @eslint-react/web-api/no-leaked-event-listener
- react-hooks/set-state-in-effect
- @eslint-react/hooks-extra/no-direct-set-state-in-use-effect
- sonarjs/different-types-comparison
- no-eq-null
- eqeqeq
- sonarjs/no-intrusive-permissions
- @typescript-eslint/no-unnecessary-type-assertion
- @typescript-eslint/no-unnecessary-conditionp
- react-hooks/refs
- import/no-namespace
- import/no-unassigned-import
- no-continue
- sonarjs/no-globals-shadowing
- react/forbid-dom-props
- @eslint-react/no-unnecessary-use-memo
- sonarjs/cognitive-complexity
- sonarjs/no-nested-conditional
- sonarjs/no-identical-functions
- @typescript-eslint/max-params
- @eslint-react/no-unstable-default-props
- @typescript-eslint/no-magic-numbers
- unicorn/prevent-abbreviations
- sonarjs/use-type-alias
- prettier/prettier
I believe that shadcn-like projects should be as strict as possible with linting to be compatible to a wide range of lint configs.
Source: AnmolSaini16/mapcn