-
-
Notifications
You must be signed in to change notification settings - Fork 689
Style Guide Alignment #205
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
Changes from all commits
470b43c
0a1237b
8b90b4a
e419479
978ddd3
180b2d4
6f4515f
18a3d8a
e64a4cb
43432b2
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,4 +1,4 @@ | ||
node_modules | ||
lib/recommended-rules.js | ||
lib/*-rules.js | ||
coverage | ||
.nyc_output |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -3,3 +3,4 @@ | |
/tests/integrations/*/node_modules | ||
/node_modules | ||
/test.* | ||
yarn.lock | ||
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -75,87 +75,109 @@ Vue.component('AsyncComponent', (resolve, reject) => { | |
## :gear: Configs | ||
|
||
This plugin provides two predefined configs: | ||
- `plugin:vue/base` - contains necessary settings for this plugin to work properly | ||
- `plugin:vue/recommended` - extends base config with recommended rules (the ones with check mark :white_check_mark: in the table below) | ||
- `plugin:vue/base` - Settings and rules to enable correct ESLint parsing | ||
- `plugin:vue/essential` - Above, plus rules to prevent errors or unintended behavior | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Those configs seems very nice, but I'm not sure we should group them like this in readme. Current groups are common in eslint ecosystem (take a look at original rules https://eslint.org/docs/rules/). Plus later we will probably have some rules that we don't want to enable in any config and give the user full freedom in deciding whether he needs it or not. With the proposed granulation we would also have to add another category - which may lead to unnecessary churn. Also I'm not sure whether maintaining 4 configs is a way to go. I'd rather keep it simple stupid and provide only There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I agree it makes sense to stick with ESLint conventions wherever there's not a compelling reason to stray, but I did see some compelling reasons here. First, I'm thinking that most people will probably discover the ESLint plugin through the style guide, so I saw a strong benefit in not forcing users to context switch after arriving here. If they want to enforce priority A rules, they'll know within seconds exactly what to do. There will be no wondering, "Wait, is Possible Errors what I want to enforce Priority A rules?" For users who have never seen the style guide, but are familiar with ESLint conventions, I don't think the new name will cause any confusion - but perhaps there's something I'm not foreseeing. What do you think? Second, I think there's value in the increased granularity. "Stylistic Issues" is too broad in my opinion, which is why I split stylistic rules between Priority B and C. For Priority B, there's one or more possible conventions that offer clear benefits over the alternatives. For Priority C, there are really many good options and the primary value is just in picking something and sticking to it. Finally, I moved
I'm not sure I understand this one. Don't users have the same amount of freedom either way, since they can override whatever they want? In terms of ease of use, I can't think of a case where more nested rule sets would worsen the user experience or make it more difficult for them to do something. Am I missing something though?
I might need more context to understand this one, because adding a new category wouldn't be a lot more code nor increase its complexity, if I'm understanding correctly. Can you provide a specific example of what you're thinking might happen?
This is another one where I might need more context. The configs are generated with a script, so I don't believe there's any extra maintenance needed. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Okay, I get your point better now @chrisvfritz Thanks for adding more context :) And regarding last three paragraphs that you quoted: Adding another group is not a big deal though, so I think that we can move forward with the current state, and iterate over it later on 👍 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @michalsnik I agree it'd be good to introduce a category like that when the need arises - and I can already think of use cases for it. For example, I like to disallow filters in many projects, because they add one more thing that developers have to learn without enabling them to do anything new. That kind of thing wouldn't fit into any (existing) categories of the style guide though. |
||
- `plugin:vue/strongly-recommended` - Above, plus rules to considerably improve code readability and/or dev experience | ||
- `plugin:vue/recommended` - Above, plus rules to enforce subjective community defaults to ensure consistency | ||
|
||
## :bulb: Rules | ||
|
||
Rules are grouped by category to help you understand their purpose. | ||
Rules are grouped by priority to help you understand their purpose. The `--fix` option on the command line automatically fixes problems reported by rules which have a wrench :wrench: below. | ||
|
||
No rules are enabled by `plugin:vue/base` config. The `plugin:vue/recommended` config enables rules that report common problems, which have a check mark :white_check_mark: below. | ||
<!--RULES_TABLE_START--> | ||
|
||
The `--fix` option on the command line automatically fixes problems reported by rules which have a wrench :wrench: below. | ||
### Base Rules (Enabling Correct ESLint Parsing) | ||
|
||
<!--RULES_TABLE_START--> | ||
Enforce all the rules in this category, as well as all higher priority rules, with: | ||
|
||
### Possible Errors | ||
``` json | ||
"extends": "plugin:vue/base" | ||
``` | ||
|
||
| | Rule ID | Description | | ||
|:---|:--------|:------------| | ||
| | [jsx-uses-vars](./docs/rules/jsx-uses-vars.md) | prevent variables used in JSX to be marked as unused | | ||
|
||
|
||
### Priority A: Essential (Error Prevention) | ||
|
||
Enforce all the rules in this category, as well as all higher priority rules, with: | ||
|
||
``` json | ||
"extends": "plugin:vue/essential" | ||
``` | ||
|
||
| | Rule ID | Description | | ||
|:---|:--------|:------------| | ||
| | [no-async-in-computed-properties](./docs/rules/no-async-in-computed-properties.md) | disallow asynchronous actions in computed properties | | ||
| | [no-dupe-keys](./docs/rules/no-dupe-keys.md) | disallow duplication of field names | | ||
| :white_check_mark: | [no-parsing-error](./docs/rules/no-parsing-error.md) | disallow parsing errors in `<template>` | | ||
| | [no-duplicate-attributes](./docs/rules/no-duplicate-attributes.md) | disallow duplication of attributes | | ||
| | [no-parsing-error](./docs/rules/no-parsing-error.md) | disallow parsing errors in `<template>` | | ||
| | [no-reserved-keys](./docs/rules/no-reserved-keys.md) | disallow overwriting reserved keys | | ||
| | [no-shared-component-data](./docs/rules/no-shared-component-data.md) | enforce component's data property to be a function | | ||
| | [no-side-effects-in-computed-properties](./docs/rules/no-side-effects-in-computed-properties.md) | disallow side effects in computed properties | | ||
| | [no-template-key](./docs/rules/no-template-key.md) | disallow `key` attribute on `<template>` | | ||
| | [no-textarea-mustache](./docs/rules/no-textarea-mustache.md) | disallow mustaches in `<textarea>` | | ||
| | [no-unused-vars](./docs/rules/no-unused-vars.md) | disallow unused variable definitions of v-for directives or scope attributes | | ||
| | [require-component-is](./docs/rules/require-component-is.md) | require `v-bind:is` of `<component>` elements | | ||
| | [require-render-return](./docs/rules/require-render-return.md) | enforce render function to always return value | | ||
| | [require-v-for-key](./docs/rules/require-v-for-key.md) | require `v-bind:key` with `v-for` directives | | ||
| | [require-valid-default-prop](./docs/rules/require-valid-default-prop.md) | enforce props default values to be valid | | ||
| | [return-in-computed-property](./docs/rules/return-in-computed-property.md) | enforce that a return statement is present in computed property | | ||
| :white_check_mark: | [valid-template-root](./docs/rules/valid-template-root.md) | enforce valid template root | | ||
| :white_check_mark: | [valid-v-bind](./docs/rules/valid-v-bind.md) | enforce valid `v-bind` directives | | ||
| :white_check_mark: | [valid-v-cloak](./docs/rules/valid-v-cloak.md) | enforce valid `v-cloak` directives | | ||
| :white_check_mark: | [valid-v-else-if](./docs/rules/valid-v-else-if.md) | enforce valid `v-else-if` directives | | ||
| :white_check_mark: | [valid-v-else](./docs/rules/valid-v-else.md) | enforce valid `v-else` directives | | ||
| :white_check_mark: | [valid-v-for](./docs/rules/valid-v-for.md) | enforce valid `v-for` directives | | ||
| :white_check_mark: | [valid-v-html](./docs/rules/valid-v-html.md) | enforce valid `v-html` directives | | ||
| :white_check_mark: | [valid-v-if](./docs/rules/valid-v-if.md) | enforce valid `v-if` directives | | ||
| :white_check_mark: | [valid-v-model](./docs/rules/valid-v-model.md) | enforce valid `v-model` directives | | ||
| :white_check_mark: | [valid-v-on](./docs/rules/valid-v-on.md) | enforce valid `v-on` directives | | ||
| :white_check_mark: | [valid-v-once](./docs/rules/valid-v-once.md) | enforce valid `v-once` directives | | ||
| :white_check_mark: | [valid-v-pre](./docs/rules/valid-v-pre.md) | enforce valid `v-pre` directives | | ||
| :white_check_mark: | [valid-v-show](./docs/rules/valid-v-show.md) | enforce valid `v-show` directives | | ||
| :white_check_mark: | [valid-v-text](./docs/rules/valid-v-text.md) | enforce valid `v-text` directives | | ||
|
||
|
||
### Best Practices | ||
|
||
| | Rule ID | Description | | ||
|:---|:--------|:------------| | ||
| :wrench: | [html-end-tags](./docs/rules/html-end-tags.md) | enforce end tag style | | ||
| | [no-async-in-computed-properties](./docs/rules/no-async-in-computed-properties.md) | disallow asynchronous actions in computed properties | | ||
| :white_check_mark: | [no-confusing-v-for-v-if](./docs/rules/no-confusing-v-for-v-if.md) | disallow confusing `v-for` and `v-if` on the same element | | ||
| | [no-duplicate-attributes](./docs/rules/no-duplicate-attributes.md) | disallow duplication of attributes | | ||
| | [no-side-effects-in-computed-properties](./docs/rules/no-side-effects-in-computed-properties.md) | disallow side effects in computed properties | | ||
| :white_check_mark: | [no-textarea-mustache](./docs/rules/no-textarea-mustache.md) | disallow mustaches in `<textarea>` | | ||
| | [order-in-components](./docs/rules/order-in-components.md) | enforce order of properties in components | | ||
| :white_check_mark: | [require-component-is](./docs/rules/require-component-is.md) | require `v-bind:is` of `<component>` elements | | ||
| | [require-default-prop](./docs/rules/require-default-prop.md) | require default value for props | | ||
| | [require-prop-types](./docs/rules/require-prop-types.md) | require type definitions in props | | ||
| :white_check_mark: | [require-v-for-key](./docs/rules/require-v-for-key.md) | require `v-bind:key` with `v-for` directives | | ||
| | [this-in-template](./docs/rules/this-in-template.md) | enforce usage of `this` in template | | ||
|
||
|
||
### Stylistic Issues | ||
| | [valid-template-root](./docs/rules/valid-template-root.md) | enforce valid template root | | ||
| | [valid-v-bind](./docs/rules/valid-v-bind.md) | enforce valid `v-bind` directives | | ||
| | [valid-v-cloak](./docs/rules/valid-v-cloak.md) | enforce valid `v-cloak` directives | | ||
| | [valid-v-else-if](./docs/rules/valid-v-else-if.md) | enforce valid `v-else-if` directives | | ||
| | [valid-v-else](./docs/rules/valid-v-else.md) | enforce valid `v-else` directives | | ||
| | [valid-v-for](./docs/rules/valid-v-for.md) | enforce valid `v-for` directives | | ||
| | [valid-v-html](./docs/rules/valid-v-html.md) | enforce valid `v-html` directives | | ||
| | [valid-v-if](./docs/rules/valid-v-if.md) | enforce valid `v-if` directives | | ||
| | [valid-v-model](./docs/rules/valid-v-model.md) | enforce valid `v-model` directives | | ||
| | [valid-v-on](./docs/rules/valid-v-on.md) | enforce valid `v-on` directives | | ||
| | [valid-v-once](./docs/rules/valid-v-once.md) | enforce valid `v-once` directives | | ||
| | [valid-v-pre](./docs/rules/valid-v-pre.md) | enforce valid `v-pre` directives | | ||
| | [valid-v-show](./docs/rules/valid-v-show.md) | enforce valid `v-show` directives | | ||
| | [valid-v-text](./docs/rules/valid-v-text.md) | enforce valid `v-text` directives | | ||
|
||
|
||
### Priority B: Strongly Recommended (Improving Readability) | ||
|
||
Enforce all the rules in this category, as well as all higher priority rules, with: | ||
|
||
``` json | ||
"extends": "plugin:vue/strongly-recommended" | ||
``` | ||
|
||
| | Rule ID | Description | | ||
|:---|:--------|:------------| | ||
| :wrench: | [attribute-hyphenation](./docs/rules/attribute-hyphenation.md) | enforce attribute naming style in template | | ||
| :wrench: | [html-end-tags](./docs/rules/html-end-tags.md) | enforce end tag style | | ||
| :wrench: | [html-indent](./docs/rules/html-indent.md) | enforce consistent indentation in `<template>` | | ||
| | [html-quotes](./docs/rules/html-quotes.md) | enforce quotes style of HTML attributes | | ||
| :wrench: | [html-self-closing](./docs/rules/html-self-closing.md) | enforce self-closing style | | ||
| | [max-attributes-per-line](./docs/rules/max-attributes-per-line.md) | enforce the maximum number of attributes per line | | ||
| :wrench: | [mustache-interpolation-spacing](./docs/rules/mustache-interpolation-spacing.md) | enforce unified spacing in mustache interpolations | | ||
| :wrench: | [name-property-casing](./docs/rules/name-property-casing.md) | enforce specific casing for the name property in Vue components | | ||
| :wrench: | [no-multi-spaces](./docs/rules/no-multi-spaces.md) | disallow multiple spaces | | ||
| | [require-default-prop](./docs/rules/require-default-prop.md) | require default value for props | | ||
| | [require-prop-types](./docs/rules/require-prop-types.md) | require type definitions in props | | ||
| :wrench: | [v-bind-style](./docs/rules/v-bind-style.md) | enforce `v-bind` directive style | | ||
| :wrench: | [v-on-style](./docs/rules/v-on-style.md) | enforce `v-on` directive style | | ||
|
||
|
||
### Variables | ||
### Priority C: Recommended (Minimizing Arbitrary Choices and Cognitive Overhead) | ||
|
||
Enforce all the rules in this category, as well as all higher priority rules, with: | ||
|
||
``` json | ||
"extends": "plugin:vue/recommended" | ||
``` | ||
|
||
| | Rule ID | Description | | ||
|:---|:--------|:------------| | ||
| :white_check_mark: | [jsx-uses-vars](./docs/rules/jsx-uses-vars.md) | prevent variables used in JSX to be marked as unused | | ||
| | [html-quotes](./docs/rules/html-quotes.md) | enforce quotes style of HTML attributes | | ||
| | [no-confusing-v-for-v-if](./docs/rules/no-confusing-v-for-v-if.md) | disallow confusing `v-for` and `v-if` on the same element | | ||
| | [order-in-components](./docs/rules/order-in-components.md) | enforce order of properties in components | | ||
| | [this-in-template](./docs/rules/this-in-template.md) | enforce usage of `this` in template | | ||
|
||
### Deprecated | ||
|
||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -15,41 +15,25 @@ Default casing is set to `always` | |
:+1: Examples of **correct** code`: | ||
|
||
```html | ||
<template> | ||
<foo my-prop="prop"> | ||
<a onClick="return false"></a> | ||
</foo> | ||
</template> | ||
<MyComponent my-prop="prop"/> | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. MyComponent is recommended? my-component? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @aladdin-add See this rule in the style guide. |
||
``` | ||
|
||
:-1: Examples of **incorrect** code`: | ||
|
||
```html | ||
<template> | ||
<foo myProp="prop"> | ||
<a onClick="return false"></a> | ||
</foo> | ||
</template> | ||
<MyComponent myProp="prop"/> | ||
``` | ||
|
||
### `"never"` - Don't use hyphenated name. (It errors on hyphens except `data-` and `aria-`.) | ||
|
||
:+1: Examples of **correct** code`: | ||
|
||
```html | ||
<template> | ||
<foo myProp="prop"> | ||
<a onClick="return false"></a> | ||
</foo> | ||
</template> | ||
<MyComponent myProp="prop"/> | ||
``` | ||
|
||
:-1: Examples of **incorrect** code`: | ||
|
||
```html | ||
<template> | ||
<foo my-prop="prop"> | ||
<a onClick="return false"></a> | ||
</foo> | ||
</template> | ||
<MyComponent my-prop="prop"/> | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wouldn't ignore yarn.lock, we might want to add it to repository
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought it'd be safer to add it to
.gitignore
until an explicit decision to include it had been made, at which time it could be easily removed. Do you disagree?