Closed
Description
Hi!
I've spotted some inconsistency/duplication with the strict
rule and wondered if this was intentional?
Currently:
- There's the eslint-config-airbnb-base/rules/strict file that declares
strict: ['error', 'never']
. - That file is only used in
eslint-config-airbnb
and noteslint-config-airbnb-base
. - Instead
eslint-config-airbnb-base
setsstrict: 'error'
manually in its rules directive (which results in the ESLint default ofstrict: ['error', 'safe']
). - However both
eslint-config-airbnb-base
andeslint-config-airbnb
setsourceType: 'module'
, which causes the ESLint strict rule to "disallow[s] strict mode directives, no matter which option is specified" regardless of those options - ie:strict: ['error', 'never']
(docs).
Issues:
- It was my understanding that for the most part, the generic (ie non react, non-AirBnb-as-as-company specific) rules/configuration belong in
eslint-config-airbnb-base
rather thaneslint-config-airbnb
, but yet theeslint-config-airbnb-base/rules/strict
extends
is contrary to that, and confusing to the end user if it actually resulted in different strict mode behaviour. - However unless people override
sourceType: 'module'
, botheslint-config-airbnb-base
andeslint-config-airbnb
actually result in the same strict mode behaviour (ie: equivalent ofstrict: ['error', 'never']
) anyway, so in most cases the rule being listed twice is just duplication rather than having any effect.
I think this situation might just be an accidental leftover from the split to the airbnb-base package (see here) and then #637.
As such, to increase consistency I would like to propose:
- Moving
eslint-config-airbnb-base/rules/strict
fromeslint-config-airbnb
'sextends
toeslint-config-airbnb-base
's (this won't affect legacy). - Deleting the manual
strict
rule definition fromeslint-config-airbnb-base
'srules
. - Probably bumping the
eslint-config-airbnb-base
major version in case there's anyone using it who setssourceType: 'script'
manually rather than using legacy, since they would see a difference in behaviour.
If this sounds acceptable, I'm happy to open a PR :-)
Metadata
Metadata
Assignees
Labels
No labels