vue/prop-name-casing should allow "onUpdate:fooBar"

[Fuzzyma]

What rule do you want to change?

vue/prop-name-casing
vue/attribute-hyphenation

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

Fewer

How will the change be implemented? (New option, new default behavior, etc.)?

New default behavior

Please provide some example code that this change will affect:

<script lang="ts" setup>
const props = defineProps({
  data: {
    type: Array as PropType<Data>,
    required: true,
  },
  'onUpdate:data': {
    type: Function as PropType<(data: Data) => any | Promise<any>>,
  },
})
</script>

What does the rule currently do for this code?

This shows a warning for 'onUpdate:data' because it is not considered camelCase. However, this is the normal description of an update handler defined via v-model

What will the rule do after it's changed?

It shouldn't warn. This is a valid prop and used if you want to have more control about the v-model cycle (e.g. awaiting a promise as in this example).

This could easily be fixed by treating : as an uppercase letter.

Additional context

vue/attribute-hyphenation is related and should also be changed. It is impossible to pass a prop like :on-update:model-value because i will complain. However, its a valid prop! I am not sure if vue supports on-update as replacement for onUpdate. If not, it should be always allowed to write onUpdate

[FloEdelmann]

I guess you are referring to https://vuejs.org/guide/components/events.html#usage-with-v-model?

onUpdate:data should be an event, not a prop.

[Fuzzyma]

@FloEdelmann v-on is just syntactic sugar on top of v-bind. For more advanced usage, it is very much required that I can specify the events as props. Vue usually even tells you, that you either have to declare emits or a prop with the event name prefixed with on. So this is not hidden knowledge and very useful under some circumstances. Eslint should allow it. If you consider it bad style, than we could ofc create a new rule for it. But the current implementation of "vue/attribute-hyphenation" only has problems with FIXING. It doesn't report this kind of props as errors. Only "prop-name-casing" does and as said above, vue allows to define events like that in your props so its wrong to report it as error

[FloEdelmann]

For more advanced usage, it is very much required that I can specify the events as props. […] very useful under some circumstances

Why? Can you share an example?

vue allows to define events like that in your props so its wrong to report it as error

Vue also allows mixing camelCase and kebab-case for different props, but that still doesn't mean it's recommended or readable.

So this is not hidden knowledge

At least I didn't know about this.

Vue usually even tells you, that you either have to declare emits or a prop with the event name prefixed with on.

But I think in the documentation, only the "event" way is used and thus recommended, right?
In https://vuejs.org/guide/components/props.html#mutating-object-array-props, the documentation states:

In most cases, the child should emit an event to let the parent perform the mutation.

@ota-meshi what's your opinion?

[Fuzzyma]

Why? Can you share an example?

The use case I use the most are those:

• I can render conditionally if an update handler was passed or not. E.g. if it's not passed, I only render the value. If it is passed I also render an edit icon
• I can call the update handler myself and also await it. That means I can wait for the update to be finished and display a spinner while updating

In both cases, the component could still be used with v-model without breaking anything

Vue also allows mixing camelCase and kebab-case for different props, but that still doesn't mean it's recommended or readable.

This is true, however, as I said: your rules already allow passing such a prop to a component. Only the fixer is broken. Defining such a prop yields an error but the error message is wrong. The prop is allowed. Maybe not recommended but definitely allowed. And it also follows the correct naming convention (pascal or kebap). So this rule should pass and not return an error.

At least I didn't know about this.

Its not something that you would use very often.

Vue usually even tells you, that you either have to declare emits or a prop with the event name prefixed with on.

That might be the case but again doesn't justify that the rules don't work correctly. The docs also got a few overhauls already. I think they mentioned it at some point. It's actually an essential part of how vue works under the hood

All in all, I don't see a reason not to allow it since only advanced users will ever do the props technically fulfill the requirements of the rules.

[ota-meshi]

If the official documentation describes how to do that, could you share it?

If it's not in the documentation, I don't think you should do it. Because I don't think it's advanced users who do things that aren't documented. If the document is simply missing, open an issue to add the document.

[Fuzzyma]

@ota-meshi the rules remain broken. How is this in any way related to the docs?

I cannot enable these rules without fixing being broken and getting false positives with misleading error messages. That alone is a reason good enough to fix these rules / accept the pr

[ota-meshi]

If it's not documented, I think it may be an unguaranteed behavior in the future. The vue/prop-name-casing rule does not accept unguaranteed behavior.

[ota-meshi]

However, you can do it even if it is not documented. You can also turn off the annoying eslint rule. You can also create an eslint plugin to do your favorite checks.

[Fuzzyma]

So using onClickas prop is fine and passing :onClick is also fine. Using @click is fine as well.

But using onUpdate:modelValue is not fine. Passing :onUpdate:modelValue is fine but breaks fixing and using @update:modelValue is perfectly valid?

This is not consistent.

If you want to restrict users from using onSomething as prop (which is your main argument), make it an extra rule (name could be "prefer-emit"). But don't leave other rules inconsistent just because of that

[ota-meshi]

If there is no documentation to explain it, the rule will not change it to support it. Thank you for your understanding.

[Fuzzyma]

@ota-meshi the rule DOES support ist!

I gave you good arguments, point out inconsistencies, discover misleading error messages and the only thing you repeat is "I can't find it in the docs". Using a prop named "onClick" is supported by your rule. So you alteady support event handlers as props. You also support passing "onUpdate:bla" without giving me any error message. It will just not make it kepap case automatically.

I get the feeling that you simply don't WANT

[FloEdelmann]

Using a prop named "onClick" is supported by your rule. So you alteady support event handlers as props.

That's just your interpretation. The rule doesn't care about whether a prop is used as an event handler or not. It just cares about casing. And it considers fooBar:baz as not camelCase, so it complains. onClick is definitely camelCase, so it doesn't complain.

I agree with your comment #1911 (comment) though: The rules are inconsistent.
@ota-meshi maybe we should indeed allow/forbid : characters and adjust the casing rules to support : in prop names in both rules.