feat(svelte): Add svelte-preprocess-unocss preprocessor for using UnoCSS in svelte-package [paused]

[jacob-8]

Closes #1719

Edit: Since it appears the hope is to add support in Svelte for svelte-package to take advantage of Vite plugins this PR is parked for the moment simply to illustrate how a svelte-preprocessor could be created. I will await the results of sveltejs/vite-plugin-svelte#475

I need help with:
- [ ] Please give advice on where to place documentation for this package. It's not a Vite plugin so it doesn't belong with the other SvelteKit docs. Perhaps a separate Svelte page, that's referenced from the main page and the Vite page?
- [ ] Add new package to NPM.

[userquin]

@jacob-8 can you take a look these?:

• https://github.com/sveltejs/vite-plugin-svelte/blob/main/docs/config.md#usevitepreprocess
• https://github.com/sveltejs/vite-plugin-svelte/tree/vite-preprocess-css-api (experimental)

I was talking with @dominikg and it seems we should avoid using another scoping solutions in svelte

[dominikg]

drafted sveltejs/vite-plugin-svelte#475 which may enable better support for vite based preprocessors in svelte-package or other svelte library tooling. Please add feedback there if possible.

[jacob-8]

I was talking with @dominikg and it seems we should avoid using another scoping solutions in svelte

Thanks for starting the conversation! Much appreciated.

drafted sveltejs/vite-plugin-svelte#475 which may enable better support for vite based preprocessors in svelte-package or other svelte library tooling. Please add feedback there if possible.

I've already published this preprocessor to a temporary package and am using it for my projects so I'm not in a rush for a fix here. I'll follow along and look forward to a good solution.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[jacob-8]

For those who still are looking for such, you can find the svelte-preprocess-unocss package on npm and read about it at https://github.com/jacob-8/svelte-scoped-uno/blob/main/packages/svelte-preprocess-unocss/README.md

[feeelX]

For those who still are looking for such, you can find the svelte-preprocess-unocss package on npm and read about it at https://github.com/jacob-8/svelte-scoped-uno/blob/main/packages/svelte-preprocess-unocss/README.md

Thank you, Jacob, for your work on implementing this feature.

Currently, we are utilizing your preprocessor, and overall, we are satisfied with its performance. However, it appears that the preprocessor is unable to detect any classes written within a <script> section. We are unsure if this limitation is specific to the svelte-scoped mode or if it is a bug. It would be helpful if you could provide some insights into this matter.

[jacob-8]

We are unsure if this limitation is specific to the svelte-scoped mode or if it is a bug.

It is a limitation. This preprocessor is heading towards being released as part of the UnoCSS family of packages (watch #2552). Even though that package is not available yet, there are a few parts of the docs that are applicable to your question. Please read how it works and then the proper usage.

For your use case, I'm going to assume building a component library since you're using the preprocessor and not the current UnoCSS vite plugin. I think you'd be better off using class directives (class:bg-green-200={color === 'green'}), but I don't know your situation, so if you must have classes in your script block I would recommend you do something like this:

<script lang="ts">
  export let color: "blue" | "green";
  $: computedClass = 'background-' + color;
</script>

<div class="{computedClass}" />

<style>
  :global(.background-blue) {
    --at-apply: bg-blue-200;
  }
  :global(.background-green) {
    --at-apply: bg-green-200;
  }
</style>

[feeelX]

We are unsure if this limitation is specific to the svelte-scoped mode or if it is a bug.

It is a limitation. This preprocessor is heading towards being released as part of the UnoCSS family of packages (watch #2552). Even though that package is not available yet, there are a few parts of the docs that are applicable to your question. Please read how it works and then the proper usage.

For your use case, I'm going to assume building a component library since you're using the preprocessor and not the current UnoCSS vite plugin. I think you'd be better off using class directives (class:bg-green-200={color === 'green'}), but I don't know your situation, so if you must have classes in your script block I would recommend you do something like this:

<script lang="ts">
  export let color: "blue" | "green";
  $: computedClass = 'background-' + color;
</script>

<div class="{computedClass}" />

<style>
  :global(.background-blue) {
    --at-apply: bg-blue-200;
  }
  :global(.background-green) {
    --at-apply: bg-green-200;
  }
</style>

Thank you for the clarification. We understand that it is a limitation and appreciate the suggested workaround.

However, what we are trying to achieve is slightly different. To provide some context, we aren't using computed class names nor are we trying to dynamically create classes. We're simply using predefined CSS classes in our script blocks which are fully written out (e.g., bg-red or flex).

For instance:

<script>
  $: variable = condition ? 'flex' : 'block'; 
</script>
<div class={variable}></div>

In the above code, the CSS class inside the script block isn't being replaced with a scoped class (e.g., uno-1234). We were under the assumption that svelte-scoped or the preprocessor would handle this scoping, and we weren't aware of this limitation, which prompted our initial question.

Based on your reply, we understand that this isn't the case. However, it's important for our use case that the classes inside the script block also get replaced with scoped classes. Is there a way to achieve this with svelte-scoped or the preprocessor, or is this a fundamental limitation of the tools?

We appreciate your help in understanding this better.

[jacob-8]

<script>
  $: variable = condition ? 'flex' : 'block'; 
</script>
<div class={variable}></div>

Then write it like this:

<div 
  class:flex={condition} 
  class:block={!condition} />

You can also do an inline expression but the above example is the recommended way.

<div class="{condition ? 'flex' : 'block'}" /> 

Reference: https://deploy-preview-2552--unocss.netlify.app/integrations/svelte-scoped#usage

[feeelX]

<script>
  $: variable = condition ? 'flex' : 'block'; 
</script>
<div class={variable}></div>

Then write it like this:

<div 
  class:flex={condition} 
  class:block={!condition} />

You can also do an inline expression but the above example is the recommended way.

<div class="{condition ? 'flex' : 'block'}" /> 

Reference: https://deploy-preview-2552--unocss.netlify.app/integrations/svelte-scoped#usage

We're aware of class directives and already use them extensively where they fit.
The previous code was just a simplified example, and the actual condition is a bit more complex.

Unfortunately, it seems that using classes inside the script block won't work for our case then.

Thanks for your help regardless.

[jacob-8]

Unfortunately, it seems that using classes inside the script block won't work for our case then.

Yeah probably not, though it's hard to give advice without having a better understanding of your use case. If you're in an app, you can use the safelist, but if you're developing one-off components that you want to be able to be used by themselves as part of a component library you're best off just using --at-apply.

[feeelX]

Unfortunately, it seems that using classes inside the script block won't work for our case then.

Yeah probably not, though it's hard to give advice without having a better understanding of your use case. If you're in an app, you can use the safelist, but if you're developing one-off components that you want to be able to be used by themselves as part of a component library you're best off just using --at-apply.

Understood. We already planned on the @apply/--at-apply method as our fallback solution, and just wanted to explore possible native alternatives. Further detail seems unnecessary.

By the way, your preprocessor has been really helpful in properly isolating our component styles. Thanks!