Release 0.18.0 breaks scan of auto-routes (unocss)

[jods4]

This commit replaced the auto-routes prefix from __ to \0.

A side-effect that was pointed out in the now removed code comments is that "using \0 like recommended in docs makes the module not be parsed by vite". The presence of this comment makes me think this drawback was initially considered an issue.

This may not seem like much, but here's one edge case:

• I have metadata in my routes, including an icon class that is used to build a navigation menu automatically;
• I have instructed Unocss to include in its pipeline **/auto-routes.
• Since 0.18.0 this file doesn't go through Vite parsing, so (my interpretation:) Unocss doesn't see it anymore.
• All classes found in that auto-routes metadata are now unknown to Unocss and I have blanks where I used to have icons in my navigation menu.

auto-routes can contain arbitrary user contents/code, from metadata or definePage hooks (beforeLoad, etc.).
Excluding it from Vite parsing can potentially create issues if that content requires compilation/processing, such as my example above.

Can you advise a workaround? Should this be reversed?

There was a link issue #608 saying __ creates conflicts with Firebase. Maybe a different prefix should be picked?

[posva]

I didn't expect it to break other integrations.

I really want to keep the virtual prefix to follow Vite conventions. My guess is that there is some mismatch with the pattern used in unocss and that it needs to be the explicit full string, not sure if with \0 or virtual: as prefix, that would be a question for Vite.

To help you debug further, use the vite inspect plugin and check for virtual modules. I hope that testing out different ids will yield the correct one 🤞 . If not, I would need help to fix this.

[jods4]

I'll try the vite inspect plugin when I have time, I'm a bit under stress at the moment so there might be delays.

What I can report right now is that I already tried to match the new id in multiple ways, including a regex /\bauto-route\b/ which should match any module having this segment inside regardless of prefix... that's why I assumed the comment "virtual modules are not parsed by Vite" came into play here.

If you need help fixing/testing let me know, as soon as I have some bandwidth I'll help.
Putting up a repro shouldn't be too complicated either, we just need a page with one unocss class in its metadata and check if we manage to get it picked up by unocss when importing the routes.

[posva]

Maybe it's by design in Vite and I shouldn't have exposed the file in the first place 😅
Can't you pass the page components directly to uno css?

[jods4]

To be honest I'm not sure about Vite internals.
Looking at this comment I'm thinking I should try without the word boundary \b regex just to test if I can catch this module. If it had an underscore _ prefix then it wouldn't be a word boundary. I'll let you know if I have some success.

Can't you pass the page components directly to uno css?

Yeah, it's an interesting situation.
I have lots of pages (like 200), all are dynamically imported routes.
The icon class names are found in those .vue files, specifically in their <route> custom block, but in dev those files are not processed by Vite nor served to browser until you actually navigate to them (when they're dynamically imported).
So unocss is totally unaware that those icons are in use and they don't load properly in the navigation menu.

What makes it work is that all those pages are collected into the routing table, and this is where all icons are referenced from at startup.
If the routing table is not seen by unocss, then it is unaware of the icons it needs until you navigate to various pages.

[posva]

Then I think you should tell the unocss wite plugin to see those .vue files. It should be fast. TailwindCSS does the same

[jods4]

I do! unocss sees them. But when you're in dev, Vite doesn't load the whole project before displaying the first page, that's why it's fast.

What happens is that unocss scans those files when they're loaded. And it makes 100% sense: before something is loaded in browser it has zero influence on the app. No need to generate classes for the whole application when only a single page is loaded.