fix(runtime-core): custom-element: ensure event names are hyphenated (fix: #5373)

[LinusBorg]

close: #5373

[netlify]

✔️ Deploy Preview for vuejs-coverage ready!

🔨 Explore the source changes: 3d55f46

🔍 Inspect the deploy log: https://app.netlify.com/sites/vuejs-coverage/deploys/6202a3cbf0d99a0008d3aa6a

😎 Browse the preview: https://deploy-preview-5378--vuejs-coverage.netlify.app

[netlify]

✔️ Deploy Preview for vue-sfc-playground ready!

🔨 Explore the source changes: 3d55f46

🔍 Inspect the deploy log: https://app.netlify.com/sites/vue-sfc-playground/deploys/6202a3cba98bb00008bd215c

😎 Browse the preview: https://deploy-preview-5378--vue-sfc-playground.netlify.app/

[netlify]

✔️ Deploy Preview for vue-next-template-explorer ready!

🔨 Explore the source changes: 3d55f46

🔍 Inspect the deploy log: https://app.netlify.com/sites/vue-next-template-explorer/deploys/6202a3cb77f1480007536f2d

😎 Browse the preview: https://deploy-preview-5378--vue-next-template-explorer.netlify.app

[LinusBorg]

My current implementation would be a breaking change as it would break camelCase listeners that were added programmatically, for example.

Could we get around this by emitting the event both in camel- and kebap-case?

That could also break something, but I'd consider that to be the most extreme of edge cases.

[yyx990803]

Could we get around this by emitting the event both in camel- and kebap-case?
That could also break something, but I'd consider that to be the most extreme of edge cases.

I think this is safer than always hyphenating. Technically, I don't think custom elements should expect case conversions for emitted events. But the mismatch between Vue conventions is also a valid issue, so I think emitting both versions is an ok compromise.