Background
ESLint officially deprecated their formatting rules in v8 and recommends Prettier for style. @stylistic/eslint-plugin was created to fill the gap for teams that weren't ready to migrate; it is not a long-term direction.
I introduced @stylistic/eslint-plugin with six hand-picked rules to approximate the previous eslint 7 settings and minimize churn. This is an incomplete formatter — it enforces a handful of style choices while leaving dozens of others to discretion or editor defaults.
The only genuinely non-standard rule in the config is key-spacing with align: { on: 'colon' }, which produces vertical colon alignment in object literals:
rules: {
'@stylistic/semi' : ['error', 'always'],
'@stylistic/key-spacing' : ['error', { align: ... }],
'@stylistic/no-multi-spaces' : 'error', // ← conflicts with the above
}
This style is not supported by Prettier, visual editors built-in formatters, or any widely used editor integration. The practical result is that every contributor whose editor auto-formats on save will produce a large, noisy diff — not because they changed logic, but because their tools disagree with the ESLint rules. This has already cost us manual cleanup work.
Why Prettier
- One canonical formatter, zero debates. Prettier makes all whitespace decisions automatically. Formatting never appears in code review.
- Universal editor support. Every major editor (VS Code, WebStorm, Neovim, Emacs) has a Prettier plugin that runs on save. Contributors don't need to configure or remember eslint to get consistent formatting.
- ESLint stays in its lane. ESLint is excellent at catching logical bugs (no-unused-vars, no-undef, etc.). Delegating formatting to a dedicated tool keeps the ESLint config small and focused on correctness, not style.
- Complete coverage. The current six @Stylistic rules still leave indentation, line length, string quotes, and object brace spacing up for grabs. Prettier covers all of these consistently with a single config option (singleQuote, semi, printWidth).
Background
ESLint officially deprecated their formatting rules in v8 and recommends Prettier for style. @stylistic/eslint-plugin was created to fill the gap for teams that weren't ready to migrate; it is not a long-term direction.
I introduced @stylistic/eslint-plugin with six hand-picked rules to approximate the previous eslint 7 settings and minimize churn. This is an incomplete formatter — it enforces a handful of style choices while leaving dozens of others to discretion or editor defaults.
The only genuinely non-standard rule in the config is key-spacing with align: { on: 'colon' }, which produces vertical colon alignment in object literals:
rules: {
'@stylistic/semi' : ['error', 'always'],
'@stylistic/key-spacing' : ['error', { align: ... }],
'@stylistic/no-multi-spaces' : 'error', // ← conflicts with the above
}
This style is not supported by Prettier, visual editors built-in formatters, or any widely used editor integration. The practical result is that every contributor whose editor auto-formats on save will produce a large, noisy diff — not because they changed logic, but because their tools disagree with the ESLint rules. This has already cost us manual cleanup work.
Why Prettier