custom-event-name-casing errors on `:`

[privatenumber]

Tell us about your environment

• ESLint version: 6.8.0
• eslint-plugin-vue version: 7.0.0-alpha.6
• Node version: v12.15.0

Please show your full configuration:
Extending plugin:vue/recommended

What did you do?

I'm using : as a delimiter to namespace my events with component-name:event-name (eg. primary-button:click)

I picked the : convention from the Vue doc on .sync: this.$emit('update:title', newTitle)

---

this.$emit('upload:change', Array.from(this.$refs.input.files));

Custom event name 'upload:change' must be kebab-case

---

this.$emit('textarea:update', val);

Custom event name 'textarea:update' must be kebab-case

---

this.$emit('tile:select-option', val);

Custom event name 'tile:select-option' must be kebab-case

---

What did you expect to happen?
To not warn on usage of : as a delimiter. Following conventions from the Vue doc on .sync:

this.$emit('update:title', newTitle)

What actually happened?

Inlined errors above code above ^

[ota-meshi]

Thank you for this issue.

Since update: is a special event name, it is not checked by custom-event-name-casing rule. The emitted update:fooBar event is used in the <template> by v-bind:foo-bar.sync. I think it's generally not intended for use with a listener called v-on:update:fooBar.

However, your event name upload:change is intended for use with v-on:upload:change.
So I think users of this component should use more than kebab-case.

The document says "we recommend you always use kebab-case for event names.". And custom-event-name-casing rule to check kebab-case.
https://vuejs.org/v2/guide/components-custom-events.html

However, you are free to choose the kebab-case. But, I think custom-event-name-casing rule is not available and should be turned off.

[privatenumber]

In terms of usage syntax, I agree v-bind:namespace:event="..." is a little confusing, but in most cases, I believe the short-hand is used which is removes that problem @namespace:event="...".

Seems the reason for kebab-case cited on the Custom Events doc is because HTML is case insensitive:

Unlike components and props, event names will never be used as variable or property names in JavaScript, so there’s no reason to use camelCase or PascalCase. Additionally, v-on event listeners inside DOM templates will be automatically transformed to lowercase (due to HTML’s case-insensitivity)

So I'm thinking the specific recommendation is to not use varying text-case in event names. Besides, the event names I'm using above are technically kebab-case (eg. name-space:event-name).

The colon : is being used as a namespace delimiter rather than a casing convention.

If custom-event-name-casing deals with name-casing, shouldn't it strictly deal with casing?

[ota-meshi]

As you say, it's enough to use all lowercase event names to avoid HTML casing issues.
But the documentation recommends kebab-case. So this rule reports non-kebab-case usage.
If you don't like this rule, you can turn it off.

As for whether the name-space:event-name is kabeb-case, I don't think it is kabeb-case. It doesn't look like a kebab.
I think namespace is another concept defined by your framework.

If we include kebab-case in the name of custom-event-name-casing rule, then this rule will not allow the option to change the casing it accepts if the documentation changes in the future. So I chose name-casing for this rule.

[privatenumber]

Hmm, then arguably update:title should be violation too? I think having a special exception isn't fair, especially if the point of the rule is to enforce a convention.

Anyway, I do like the rule--to the point where I'm filing an issue to share a user perspective with hopes to help improve it.

Could we consider an option, eg. ignoreCharacters: [':'], allowCharacters: [':'], or allowNamespace: true?

[ota-meshi]

update:title is not reported. This is a special event name for Vue.js. Even if you specify camelCase, users can use it in kebab-case with .sync. And users don't have to specify update:

I think we can consider the new option. If you would like to suggest a new option, could you open a new issue to avoid confusion?

[privatenumber]

Closed in favor of #1260