Replies: 2 comments 4 replies
-
|
I ran into the same issue while setting up Tailwind with Nuxt. The TypeScript error happens because the plugin returned by import tailwindcss from "@tailwindcss/vite"
export default defineNuxtConfig({
compatibilityDate: "2025-07-15",
devtools: { enabled: true },
vite: {
plugins: [
tailwindcss() as any,
],
},
})I also hit the 404 error mentioned in step 5 of the guide. The path in the docs uses css: ['~/assets/css/main.css']After updating the path, the stylesheet loaded correctly and the 404 error disappeared. Might be worth updating the docs to reflect this |
Beta Was this translation helpful? Give feedback.
-
|
This is completely unrelated to the discussion at hand here... |
Beta Was this translation helpful? Give feedback.
-
|
You're right my mistake. I mixed this up with a Nuxt + Tailwind setup issue. |
Beta Was this translation helpful? Give feedback.
-
|
One possible approach could be exposing the filter chain so plugins can append to it instead of redefining the whole property. CSS If there were a shared extension point (for example something like That would keep the composable model while making custom filter utilities easier to extend. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, I was thinking about something similar, but unless the extension point somehow supports multiplicity, this would not prevent different plugins from conflicting with each other. For example, let's say we have two plugins or packaged utilities: @utility filter-a {
--tw-custom-filter: url(...);
}@utility filter-b {
--tw-custom-filter: url(...);
}Then it would not be compatible with using both of them simultaneously (unless both packages agree on some intermediate convention to combine into a single extension point, which just nudges the problem) @import 'tailwindcss-filter-a';
@import 'tailwindcss-filter-b';<div class="filter-a filter-b">...<div>This is fundamentally similar to the limitations faced with animation/transition plugins which generally define their own internal property lists. I think it boils down to needing an API let utilities co-extend lists defined by both default utilities and custom utilities / plugins. This likely will need to rely on compile-time heuristics beyond css variables chaining. Maybe something along the lines of: /* signaling to tailwind based on theme property naming */
@theme {
--filter-foo: ;
}
@utility filter-foo {
--filter-foo: url(...);
}
/* or using the @property multiplier (+ or #) syntax on target properties. */
@utility filter-bar {
filter#: url(...);
}
/* or using some custom function */
@utility filter-baz {
filter: --append(url(...));
} |
Beta Was this translation helpful? Give feedback.
-
|
That makes sense the conflict between multiple plugins targeting the same extension point is the tricky part. Maybe instead of a single variable like So each plugin would contribute its own variable, for example: CSS and Tailwind would merge them into the final filter chain during generation. That way plugins wouldn’t need to coordinate conventions between themselves and the composability model would stay intact. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Some default utilities rely on pre-defined css variable chains to compose the value of a single css property. One example would be filter utilities which include a common filter chain that translates into something like
When wanting to create custom filter utilities using either the
@utilitysyntax or the js plugin API, we need to either throw that system out completely or manually redeclare an extended version of the variable chain (without guarantee that other custom utilities would be compatible). Could there be an API to conventionally extend such variable chains such that both default utilities and custom ones would take into account the updated base?Beta Was this translation helpful? Give feedback.
All reactions