-
Notifications
You must be signed in to change notification settings - Fork 664
📎 Consider disabling all lint rules by default #1529
Comments
Just a quick note from our conversation We can have flags for easily turning on different rulesets: {
"rome": {
"lint": {
"recommended": true
}
}
} |
Why? What good are lint rules if they're not on by default? |
"Turned off by default" is probably the wrong answer. I would prefer turned on by default, but have everything turned off as soon as you started providing config with a simple way to get turn the base recommended stuff on. |
Gotcha, that makes sense - meaning, the default config is not "an empty object", it's "something like in your previous comment". |
Maybe something like this: {
"rome": {
// no linting
"lint": false,
// recommended rules
"lint": true,
// react rules
"lint": { "rules": { "react": true } },
// recommended+react rules
"lint": { "rules": { "recommended": true, "react": true } },
}
} |
Some more thoughts:
So we'd have metadata about the rules that looks like: const Rules = {
a11y: {
recommended: true,
rules: {
noAccessKey: {
recommended: true,
},
noAriaUnsupportedElements: {
recommended: false,
},
},
},
react: {
recommended: false,
rules: {
noArrayIndexKey: {
recommended: false,
},
noDirectMutationState: {
recommended: true,
}
},
},
// etc...
} as const That would work like this: {
"rome": {
// turn linting off (default)
"lint": false,
// turn linting on
"lint": true,
// turn linting on, but customize it
"lint": {
// customize the rules (default: `{ "recommended": true }`)
"rules": {
// turn recommended categories off
"recommended": false,
// turn recommended categories on
"recommended": true,
// turn a specific category on (overriding `recommended`)
"react": true,
// true a specific category off (overriding `recommended`)
"a11y": false,
// turn a specific category on, but customize it
"a11y": {
// turn recommended rules off
"recommended": false,
// turn recommended rules on
"recommended": true,
// turn a specific rule on (overriding `recommended`)
"noArrayIndexKey": true,
// turn a specific rule off (overriding `recommended`)
"noDirectMutationState": false,
}
}
}
}
} Some examples:Turning on the recommended categories:{
"rules": { "recommended": true },
// expands into:
"rules": { "a11y": true, "react": false },
// expands into:
"rules": { "a11y": { "recommended": true }, "react": false },
// expands into:
"rules": { "a11y": { "noAccessKey": true, "noAriaUnsupportedElements": false }, "react": false },
} Turning on the "react" category:{
"rules": { "react": true },
// expands into:
"rules": { "a11y": false, "react": true },
// expands into:
"rules": { "a11y": false, "react": { "recommended": true } },
// expands into:
"rules": { "a11y": false, "react": { "noArrayIndexKey": false, "noDirectMutationState": true } },
} Turning on the "react" category with specific rules:{
"rules": { "react": { "noArrayIndexKey": true } },
// expands into:
"rules": { "a11y": false, "react": { "noArrayIndexKey": true } },
// expands into
"rules": { "a11y": false, "react": { "noArrayIndexKey": true, "noDirectMutationState": false } },
} |
I like this configuration. My only concern is how big a configuration file might become (test, lint, bundling, etc.). Maybe, in the future, we might think of a way to splitting it. |
The
I think the natural argument is why not support dynamic configuration via a |
Oh nice! I didn't think about it! Then problem solved |
No description provided.
The text was updated successfully, but these errors were encountered: