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).

[acalvino4]

When v4 first came out, I found the lack of good plugin docs an annoying oversight, but forgivable given the otherwise awesome evolution of the framework - but it's now been out for 9 months, so I'm beginning to find it a bit more concerning. Does the team intend to support plugins as a first-class feature, or are they just an afterthought that covers a few trivial non-core cases but not much else? Are js (so called "legacy") plugins going to be deprecated at some point? If so, will there be another way to do everything they do? Currently it's anyone's best guess.

v3 had a full page documenting how to do various things via a plugin. v4 has only a small section on adding custom utilities, and a note that the @plugin directive still works but is "legacy". A few other details can be gleaned from github threads like this, but that really shouldn't be necessary.

Some of the questions that need answering in the docs are:

• What is a Tailwind v4 plugin? (a js file? a css file? sometimes one and sometimes the other? an obsolete concept?)
• Why are js files considered legacy if they are still the only way to do certain things? (to me it seems that either they shouldn't be, or there should be an outline of how the likes of iconify and daisyui will eventually be able to work as pure css plugins)
• How, via a plugin, would I
  • Override base layer styles?
  • Disable certain utilities?
  • Override certain utilities? (maybe just disable, then redefine, assuming 'how do disable' gets an answer?)
• How could a css plugin register and consume its own custom options? (see v3 analog)
• How do I publish a css tw plugin as a distributable npm package?
• How do I consume a tw plugin from an npm package in a css tw config file?

@philipp-spiess perhaps you could weigh in here? not necessarily to provide answers to all these questions, which I realize you might not have, but at least to update the community and then prioritize a docs update with the team.