Skip to content
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

vue/html-self-closing doesn't work when used with prettier #2232

Open
yoshi-pi opened this issue Jul 7, 2023 · 10 comments
Open

vue/html-self-closing doesn't work when used with prettier #2232

yoshi-pi opened this issue Jul 7, 2023 · 10 comments

Comments

@yoshi-pi
Copy link

yoshi-pi commented Jul 7, 2023

What rule do you want to change?
vue/html-self-closing

Does this change cause the rule to produce more or fewer warnings?
No

How will the change be implemented? (New option, new default behavior, etc.)?
The change will be implemented by dividing the html.void option into two distinct rules.

Additional context
Currently the html.void option in vue/html-self-closing is causing conflicts with prettier, so vue/html-self-closing is turned off in eslint-config-prettier. Because of this, when ESLint and prettier are used together, vue/html-self-closing is not available by default even if plugin:vue/vue3-recommended is set.

<MyComp></MyComp> // not throw error with prettier

I think the solution is to create another new rule with only the html.void option and turn off that option in eslint-config-prettier configuration file. What do you think?

Update:
I have an additional question. Is it necessary to lint tags other than Vue components using eslint-vue-plugin?

@lydell
Copy link

lydell commented Jul 7, 2023

Because of this, vue/html-self-closing cannot be used when ESLint and prettier are used together.

That’s not true. As mentioned in the eslint-config-prettier docs you linked to:

If you like this rule, it can be used just fine with Prettier as long as you set html.void to "any".

The gist of it:

{
  "extends": [
    "something-vue",
    "prettier"
  ],
  "rules": {
    "vue/html-self-closing": [
      "error",
      {
        "html": {
          "void": "any"
        }
      }
    ]
  }
}

@yoshi-pi
Copy link
Author

yoshi-pi commented Jul 8, 2023

Sorry, I didn't explain it well enough.
I meant that vue/html-self-closing is not available by default when used with prettier. Edited the text.
I think it is not a good developer experience to have to describe this setting to get the best practice.

@FloEdelmann
Copy link
Member

Is it necessary to lint tags other than Vue components using eslint-vue-plugin?

Yes; not everyone is using Prettier, but still most want to stick to some consistent formatting in the Vue SFC template block.

I think the solution is to create another new rule with only the html.void option and turn off that option in eslint-config-prettier configuration file.

Why not change the default options in eslint-config-prettier instead?

@yoshi-pi
Copy link
Author

Why not change the default options in eslint-config-prettier instead?

If the default options in eslint-config-prettier are changed, the vue/html-self-closing rule will be applied to all users who are using eslint-config-prettier. So, for example, people using plugin:vue/vue3-essential will also have vue/html-self-closing applied. eslint-config-prettier is only intended to remove rules that conflict with prettier. So it is still a good idea to change the vue/html-self-closing rules.

@gyohza
Copy link

gyohza commented Sep 11, 2023

Pardon my ignorance, but do we really need this rule? In the rule docs there's this bit:

Self-closing is simple and shorter, but it's not supported in the HTML spec.

But what do they mean by "not supported"? What should be expected by said support? Here's what the WHATWG specs say:

Then, if the element is one of the void elements, or if the element is a foreign element, then there may be a single U+002F SOLIDUS character (/), which on foreign elements marks the start tag as self-closing. On void elements, it does not mark the start tag as self-closing but instead is unnecessary and has no effect of any kind.

For such void elements, it should be used only with caution — especially since, if directly preceded by an unquoted attribute value, it becomes part of the attribute value rather than being discarded by the parser.

So even though it doesn't really "do" anything meaningful, it doesn't necessarily create an issue, either - especially considering that quotes can be enforced with vue/html-quotes (the problem mentioned in the second paragraph would never happen).

I don't appreciate that Prettier enforces self-closing, either, but if it's not really a problem, why add it as warn rule by default? Unless, of course, it were a problem - I would appreciate if you could enlighten me.

@yoshi-pi
Copy link
Author

@gyohza
It is being discussed in #5246. For your reference.

@FloEdelmann
Copy link
Member

I don't know why the default for html.void is never. @ota-meshi do you know that?

if it's not really a problem, why add it as warn rule by default

Hmm we also have other rules that enforce a style convention instead of preventing a problem. And it's in the "strongly recommended" preset config because it's included in the same section in the Style Guide: https://vuejs.org/style-guide/rules-strongly-recommended.html#self-closing-components

Indeed, I like the explanation in prettier/prettier#5246 (comment):

The moment you see a self-closing tag, you understand it's void. Otherwise you have to remember which tags are void.

I'd be fine with changing the default to always for void elements, too. But that would be a breaking change, so it can only be done in a major version.

@ota-meshi
Copy link
Member

ota-meshi commented Nov 21, 2023

Many of the stylistic rules in this plugin were released before Prettier full supported *.vue. I think many of the rule defaults are implementer's preference, unless they follow the Vue style guide.

I don't want to change the rule defaults. This is because people who like the current style complain.

@yoshi-pi
Copy link
Author

Ah, I understand. So, we simply need to change the default values.

I don't want to change the rule defaults. This is because people who like the current style complain.

Indeed, some people might express dissatisfaction if void elements become self-closing. It's a trade-off. In that case, splitting the rules into two might be one way to go after all.

@FloEdelmann
Copy link
Member

I'd be fine with changing the default to always for void elements, too. But that would be a breaking change, so it can only be done in a major version.

I don't want to change the rule defaults. This is because people who like the current style complain.

@ota-meshi Should we reconsider this for v10? Some people will complain either way. But Prettier has become such a widely used tool that making the rule compatible with Prettier will likely benefit more people than leaving it as is. Also, people not using Prettier who like the current style can still override the default settings.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants