limitation with tailwind presets due to custom extractor -- (blocked from using fluid-tailwind in preset)

[firxworx]

Thanks again for an amazing solution for fluid responsive designs in tailwind! It is now my standard for any new project!

I am submitting this issue to report a limitation using fluid-tailwind with presets.

Issue

Tailwind does not support specifying content in a preset therefore one can't add fluid-tailwind's extractor to enable ~ syntax and thus one can't define fluid styles/typography/etc.

For reference see type PresetsConfig as exported by tailwindcss/types/config and its exclusion of content because this should be the job of an actual tailwind config vs. a preset.

Motivation

Presets are ideal for sharing common styles and design systems across projects. They can be published and when presets are added to a tailwind config, multiple presets get intelligently merged order and finally a theme config has precedence over any presets. They're also super useful for defining a common "plugin stack".

A preset for a brand or design system can define standard sets of plugins plus spacing, gap, typography, etc. -- all places where it would be ideal to use fluid-tailwind.

I appreciate that ~ is a fundamental design decision with this library. I also totally appreciate the advantages of this convention. I figure perhaps an issue report will get your brilliant mind spinning, or at the very least documenting this limitation for others.

In the big picture I think #42 is related as it ultimately also has to do with defining reusable preset/configuration settings and defining a reusable/shareable theme.

Workarounds

At least for now in my preset in my @tailwindcss/typography theme I actually set fontSize and lineHeight based on values generated fluid-tailwind utilities I add to my apps e.g. ~text-sm/base and then copy and paste from IntlliSense.

Unfortunately this isn't as maintainable or portable e.g. if sm is redefined for a theme then all the values are wrong.

Ideas

Its too bad that presets can't specify custom extractors too (perhaps this is ultimately a tailwind issue?).

For the time being another idea is fluid-tailwind could export helper utilities that could be used in presets and plugins for generating values that would be generated by fluid-tailwind for ~ utility classes.

Perhaps one could write a tailwind config factory or create another export specifically for config files that specifies customizations that require fluid ~ utilities, although this approach compromises presets key features and DX of presets.

[barvian]

Hey, thanks for the big write-up! I definitely hear the concerns about the extractor being incompatible with presets. I like the idea of utility functions and I think I may experiment with them. The API will likely be a little clunky but that seems unavoidable. I could definitely see this being useful for things like spacing that are shared among many utilities. 🤔