ESLint plugin with stylistic code formatting rules that are often nitpicked in code review by quibbly developers.
npm install eslint-plugin-quibble!npm latest version !license !downloads
Learn more about each supported rules by reading their documentation:
- no-excessive-whitespace: removes unnecessary whitespace characters, including leading and trailing spaces, as well as multiple spaces between class names.
By using ESLint extension for Visual Studio Code, you will get the following messages:
!errors
The vue-no-excessive-whitespace was renamed to no-excessive-whitespace and {j,t}sx support was added.
Check out the full changelog here.
``
pnpm i -D eslint eslint-plugin-quibble
- (Optional) Install Vue parser: pnpm i -D vue-eslint-parser
- Inside your eslint.config.js:
`js
import quibble from 'eslint-plugin-quibble'
export default [
{
plugins: {
quibble
},
rules: {
'quibble/no-excessive-whitespace': 'error'
},
},
{
files: ['*.vue'],
languageOptions: {
parser: 'vue-eslint-parser',
}
},
]
`
Adding vue-eslint-parser is optional - some popular configs such as antfu/eslint-config have it installed and configured already.
In the future, this plugin will be expanded by the rules the community or myself find worth of adding.
To argue about, or say you disapprove of, something that is not important:
- _There's no point quibbling about/over a couple of ~~dollars~~ whitespace characters_.
To be perfectly honest, when doing code reviews at work, I often spot excessive whitespace characters, typos, or other stylistic errors - and it really irks me.
Should I nitpick the PR and point out those lines, saying:
> Hey, could you remove this whitespace? I know it doesn't change much, but I'd be pleased to see it gone from the codebase. :)
Well, probably not. It's annoying to impose stylistic rules on developers that cannot be auto-fixed by their IDE - something I've learned from Theo. That's why I've developed this ESLint plugin.
Side note: The other option, to avoid making my fellow developers angry with me, was delivering the nitpicks in the form of a meme, which I actually did (at least) once #meme-driven-development.
There are a few reasons why. The primary one is that I wanted to finally build a tool on my own. I've spent countless hours configuring ESLint to work the way I want, and my curiosity about how it works internally eventually won.
The second reason why, it takes time to get your PR reviewed, accepted and published. Where would the no-excessive-whitespace rule even fit? eslint-plugin-perfectionist, eslint-stylistic or maybe eslint-plugin-tailwindcss? There's an issue opened on the last one since Jul 21, 2023.
Therefore, it was easier to create a plugin from scratch - something I have a full control of, can use right away, and can learn from in the process.
Yes! I very much welcome the community's input, and I would be pleased to see your ideas on how to expand or improve this plugin. Feel free to open an issue. :)
Following Anthony Fu's example with antfu/eslint-config, I'm migrating my projects to use only ESLint for both syntax highlighting and code formatting. Although prettier/eslint-plugin-prettier exists, I found it too annoying to configure both Prettier and ESLint, especially with the conflicts that can arise between the two.
Yes.
You can check out your ESLint config by using the official tool - ESLint Config Inspector:
`
pnpm dlx @eslint/config-inspector@latest
I was heavily inspired by eslint-plugin-tailwindcss and eslint-plugin-vue as the source code (structure, methods of crawling into nodes, naming conventions etc.) for those plugins was essentially my entry point and the base to creating eslint-plugin-quibble`.