💥 Force camelCase in Vue everywhere, including props/attrs

[ShGKme]

Proposal

• 'vue/component-name-in-template-casing': ['error', 'PascalCase] (✅ default, used)
• 'vue/custom-event-name-casing': ['error', 'camelCase'] (✅ default, used)
• 'vue/slot-name-casing': ['error', 'camelCase'] (➕ default, add the rule)
• 'vue/attribute-hyphenation': ['error', 'never'] (💥 opposite, change)

Motivation

1. Having different cases in template and script makes it harder to find prop usage with a simple search
2. Different tooling handle kebab-case worse, for example, with the new v-bind shortcut syntax <Tag :foo-bar /> from fooBar property, with refactoring and etc.
3. After introducing slot-name-casing, attributes are the only with kebab-case

Isn't it against Vue Style Guide?

Not really, now both styles are correct if consistent: https://vuejs.org/style-guide/rules-strongly-recommended.html#prop-name-casing

In addition, the Vue Style Guide is:

• Not permanent: just recently <kebab-case> was the recommended default to component names in the template
• Not consistent: PascalCase/camelCase for components, event, slots and kebab for props
• Sometimes slow to adapt: before supporting in-dom templates was more important than nowadays, Vue 3 Style Guide was in active development for a long time after the Vue 3 release

[ShGKme]

This is not formally a breaking change, but it has a huge impact on the code changes

[Sector6759]

Hey, regarding slot names, in contrast to prop names, slot names aren't automatically mapped from kebab-case to camelCase. So using a slot like

<template #foo-bar></template>

only works if the slot was defined with exactly this casing:

<slot name="foo-bar"/>

So if the linked PR is merged and @nextcloud/vue updates its code according to this lint rule, existing usages of Nextcloud's Vue components will break if a multi-word slot name is used on said components, e.g. the NcListItem component has several slots using a multi-word name: extra-actions, actions-icon.

TL;DR: linting the code of @nextcloud/vue according to this change, will break code using certain components of that package.

[ShGKme]

vue/slot-name-casing is about naming slots, not using slots.

This means that if @nextcloud/vue component has foo-bar slot, it will be used as before

<!-- No errors for the slot user -->
<template #foo-bar></template>

In contrast, it forces component developers to name slots accordingly:

<!-- There will be an error -->
<slot name="foo-bar" />

This rule does not change the name automatically. And if a developer renames the slots - this is the developer who introduced the breaking change. Not the rule.

In other words, it is exactly the same as with vue/no-boolean-default rule.

defineProps({
  // vue/no-boolean-default doesn't allow it
  showStatus: {
    type: Boolean,
    default: true,
  }
})

Renaming the prop above from showStatus to hideStatus with default false is a breaking change. It is on the library developers' responsibility.

To simplify migration, library developers can introduce a new prop while keeping the old one as deprecated.

Exactly the same is possible in with slots.

<!-- new slot -->
<slot name="fooBar">
  <!-- @deprecated fallback -->
  <slot name="foo-bar" />
</slot>