v4 third party plugins

[skttl]

Congratulations on getting v4 out!

I am missing documentation for creating third party plugins in the docs (v3: https://v3.tailwindcss.com/docs/plugins).

Is this not supported anymore?

[wongjn]

You should be able to do most things in a CSS file now, with new at-rules like @utility, @custom-variant, etc. For existing v3 plugins, you can include them via the @plugin at-rule.

[skttl]

Thanks

So, if I want to be able to share a plugin like on npm, it has to be in the v3 format?

[wongjn]

You can have it as a CSS file and consumers can @import it in their own CSS.

[skttl]

Thanks, the new at-rules looks great - need to play around with them :)

[browner12]

I see the container queries have been pulled in to the main codebase. What is the status of the other 3 (typography, forms, and aspect-ratio). Should those still be pulled in via the @plugin if you need them?

[stijns96]

For those who use prettier, add /* prettier-ignore */ above it.

Did you find a way to prevent it from removing the trailing semicolon? 😩

Nope..

[manuel3108]

Since the @plugin trick should only be used for "legacy" plugins according to the docs, what is the expected way to go forward?

Will those plugins be included into the core at some point? Or are the docs misstating that this is a legacy feature? I'm not quite understanding what the current plan is, so I would be happy if anyone can elaborate.

[m6io]

I came to ask the same question as @manuel3108

[wongjn]

I believe the expectation is that plugins are now CSS files that have @utility and/or @custom-variant to do plugin things.

[manuel3108]

Do I understand that correctly, that the forms and typography will therefore be updated to support the new syntax?

Background: we are currently updating the svelte project scaffolding tool sv to support tailwindcss@4. Previously users had the possibility to select which of those 3 plugins they wanted to use and we integrated them for the user. Therefore I'm currently trying to understand if we need to keep that prompt, and which source code should be generated in that case.

As of my understanding as of now, using the "legacy" @plugin syntax is the de-facto standard for those two forms and typography plugins as of today. If my conclusion is wrong, please let me know!

[acalvino4]

Plugins could definitely use better documentation in v4, if only to say explicitly that they are being replaced by the @utility directive and .css files. As it stands, it is not clear to me whether that will cover all use cases that js plugins used to, and whether that means that @plugin will be deprecated at some point in the future. (Between the release statement, migration guide, and docs, the only mention of this atm seems to be the note that the @plugin directive is present for legacy plugins.)

As some examples, I noticed that daisyui and iconify plugins are still using this "legacy" method, and while i haven't done extensive work developing tw plugins, I have a hard time seeing how these plugins could be reimplemented using just @utility and css. If that is correct, it would seem that js plugins shouldn't be considered a "legacy" feature and that the docs should instead try to outline when you might want to use just css vs actually developing a plugin.

[stijns96]

I'm also really curious about this. There is an open issue for TW Fluid to support TW 4, but I really don't see how this could be developed without js. @wongjn could you please come back on this as I think the meed for clarifacation becomes bigger and bigger.

CSS becomes more powerfull, but JS is much more powerfull

[wongjn]

This is something for the maintainers to comment on really. I've still seen them recommend the JavaScript API in some instances, for example: #17460 (comment).