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

[yoshi-pi]

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]

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]

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]

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]

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]

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]

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

[FloEdelmann]

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]

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]

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]

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.