-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Styleguide] Revert chain indentation rule or update the entire codebase #12729
Comments
I proposed the change precisely because the existing style rule was inconsistently being applied across the codebase despite being documented. I'm not sure why that was the case, though I have ideas. We should bulk update the codebase on styleguide change wherever practical though. |
If it's in the styleguide I think eslint should fail on it. Then we're pushed towards either removing it or doing a bulk update. Imo PRs shouldn't stall because of style discussions, unless it's a "new problem" we haven't covered yet. |
(unless it's things eslint can't easily check, of course) |
@kjbekkelund totally agree. I'd take it a step further and say new styleguide rules shouldn't be introduced without an accompanying eslint rule (if possible) and a bulk update to existing code. Otherwise the new rule only creates more inconsistency, as is happening here. |
We could even move the explanation of style rules into the eslint config itself, "coupled" to the eslint rule that enforces it. Then the Kibana styleguide becomes just the higher-level "non-eslint-able" stuff. And it should be way easier to keep eslint and explanation consistent too. (Or maybe we should just explore Prettier, and not have to think about (and discuss) these things at all 🙈) |
I currently assigned the platform team to this, due to owning eslint and prettier (afaik). Please feel free to close this issue, if it's no longer relevant. |
The chain indentation rule in our styleguide was inverted awhile back without much thought by #7435. A styleguide should create consistency, this rule is having the opposite effect. We should either revert the rule change or fix the entire codebase in one go (I'd be in favor of simply reverting). Applying this rule selectively to new code only makes the codebase worse.
The text was updated successfully, but these errors were encountered: