amannn
commented
6 days ago As discussed in the CL issue, I did an analysis of whether @nkzw-tech/eslint-config or eslint-config-molindo would be a better fit for us to get rid of the Airbnb ESLint config (which is no longer maintained) and use another base config to benefit from up-to-date rules.
"Being a better fit" can be measured along different characteristics.
The approach I took here is the following:
- Replaced the Airbnb config in the CL with one of the candidates
- Ran ESLint
- Checked how many unique rule violations there are (notable not how many errors, but how many unique errors—given that stylistic errors can usually be autofixed)
Here are the results, categorized by my personal judgment of if we'd like to adopt rules that report errors.
@nkzw-tech/eslint-config
Good
- react/display-name
- react/jsx-key
- unicorn/prefer-array-index-of
- unicorn/prefer-optional-catch-binding
- unicorn/no-useless-spread
Debatable
- unicorn/prefer-node-protocol
- unicorn/prefer-number-properties
- unicorn/prefer-string-replace-all
- unicorn/prefer-dom-node-append
- curly
Too opinionated
- sort-keys-fix/sort-keys-fix
- typescript-sort-keys/interface
- import/no-namespace
- unicorn/consistent-function-scoping
- unicorn/numeric-separators-style
- unicorn/prefer-native-coercion-functions
- unicorn/prefer-ternary
- no-constant-binary-expression
- unicorn/catch-error-name
- unicorn/text-encoding-identifier-case
- @nkzw/no-instanceof
eslint-config-molindo
Good
- react/display-name
- react/jsx-key
- jsx-a11y/no-autofocus
Debatable
- @typescript-eslint/explicit-member-accessibility
- unicorn/explicit-length-check
- curly
- array-callback-return
Too opinionated:
- react/jsx-handler-names
So based on this analysis, it seems like both configs have useful rules that we could benefit from and I think we should enable them.
On a different characteristic, I think eslint-config-molindo has an advantage in not being monolithic, but allows to choose which particular rules to enable (also providing opt-in support for CSS modules for example).
Another aspect is ESLint 9 compatibility. Both configs are currently not updated for ESLint 9, the one from nkzw-tech currently even downgrading an upstream dependency to stick to ESLint 8 support (https://github.com/nkzw-tech/eslint-config/commit/5240db66901666d703cd3c88cc88f6f13b6ef3d4).
As mentioned, I maintain eslint-config-molindo, so if we'd go for this, we'd have the advantage that I can for example upgrade the upstream package for us to get ESLint 9 support.
I think based on this, I'd vote for eslint-config-molindo, happy to hear other opinions!
Action plan: