fix: issue where c type is any

[vinayakkulkarni]

While running nuxt app, I was getting the error c.toUpperCase is not a function, after digging in the vite builds, found out that these functions classify & camelize are the root cause.

• This PR fixes the issue (we have c which is of type any & toUpperString() only works on String prototype.

Issue Repro –

1. Clone – https://github.com/geoql/expenses
2. npm ci
3. npm run dev

For context, Nuxi info

------------------------------
- Operating System: Darwin
- Node Version:     v20.4.0
- Nuxt Version:     3.6.5
- Nitro Version:    2.5.2
- Package Manager:  [email protected]
- Builder:          vite
- User Config:      app, components, css, devtools, experimental, vue, ssr, modules, nitro, plugins, routeRules, runtimeConfig, typescript
- Runtime Modules:  @pinia/[email protected], @vueuse/[email protected], @nuxtjs/[email protected], @unocss/[email protected]
- Build Modules:    -
------------------------------

[github-actions]

Size Report

Bundles

File	Size	Gzip	Brotli
runtime-dom.global.prod.js	85.8 kB (-60 B)	32.6 kB (-40 B)	29.4 kB (-35 B)
vue.global.prod.js	132 kB (-60 B)	49.3 kB (-14 B)	44.3 kB (-9 B)

Usages

Name	Size	Gzip	Brotli
createApp	47.8 kB (-121 B)	18.9 kB (+8 B)	17.2 kB (+7 B)
createSSRApp	50.5 kB (-121 B)	19.9 kB (-4 B)	18.2 kB (-3 B)
defineCustomElement	50.1 kB (-121 B)	19.6 kB (-10 B)	17.9 kB (+5 B)
overall	61.1 kB (-100 B)	23.7 kB	21.6 kB (-3 B)

[skirtles-code]

I'm not sure I understand the use case here. Is there a legitimate reason for these functions to accept values that aren't strings? Isn't calling toString() just hiding the problem rather than fixing it? Perhaps it would be better to add a warning somewhere further up the callstack to report the original mistake that led to these values not being strings in the first place?

[schelmo]

seems like the same unocss bug like here:
unocss/unocss#3206

[mklueh]

I ran into the same problem, more details here:

nuxt/nuxt#23937 (comment)

In my case, it was caused by the kebab case component property convention, which seems to not work anymore.

This does not work anymore / produces the hydration failures

      <PostItem :class="{'shadow-lg hover:-translate-y-1': useGridView}"
                v-for="post in posts"
                :key="post.id"
                :post="post"
                :show-border="!useGridView" />

while this works

      <PostItem :class="{'shadow-lg hover:-translate-y-1': useGridView}"
                v-for="post in posts"
                :key="post.id"
                :post="post"
                :showBorder="!useGridView" />

Not sure what causes this and I assume not everybody is facing this issue, as this would probably go viral.

[skirtles-code]

Based on the UnoCSS bug report linked above, I think this PR should be closed.

UnoCSS is rewriting some of the code in Vue. The original code contains this line:

const camelizeRE = /-(\w)/g

By the time it gets to the browser, it has been changed to this:

var camelizeRE = /-\w/g;

The parentheses have been removed, leading to the replace callback being passed the wrong arguments.

I've checked this myself and confirmed that this is what's happening in the original reproduction. I haven't dug in to confirm that UnoCSS is the root cause, but something is rewriting that RegExp, so there's nothing that needs to be done in Vue to fix it.