#80·mapcn

[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.