* Reduce specificity of `rtl`, `ltr`, and `dark` variants
Reduce specificity of `rtl`, `ltr`, and `dark` variants (when using `darkMode: 'class'`) to make them the same as other variants. This also sorts the LTR/RTL and dark variants later in the variant plugin list to ensure that the reduced specificity doesn't cause them to start "losing" to other variants to keep things as backwards compatible as possible.
Resolves a long-standing issue where `darkMode: 'media'` and `darkMode: 'class'` had different specificity, which meant switching your dark mode strategy could break your site.
* Update changelog
---------
Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
* add `*` as child variant
* add `*` as allowed variant character
* update test to reflect Lightning CSS output
* add `childVariant` test
* Update changelog
---------
Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
Co-authored-by: Gregor Kaczmarczyk <github@aggreggator.de>
* Add forced-colors variant
Also add a contrast-custom variant to match custom contrast preferences
* use `toMatchSnapshot` instead of `toMatchFormattedCss`
More info: https://github.com/tailwindlabs/tailwindcss/pull/12170
* remove `contrast-custom` variant
* move `forcedColorsVariants` next to `prefersContrastVariants`
* update changelog
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
* Add `has-*` variants for `:has(...)` pseudo-class
* Update changelog
* Fix mistake in test
---------
Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
* Skip over classes inside `:not(…)` when nested in an at-rule
When defining a utility we skip over classes inside `:not(…)` but we missed doing this when classes were contained within an at-rule. This fixes that.
* Update changelog
* Refactor
* Don’t prefix classes in arbitrary values for group and peer
* use `foo` instead of `lol`
* handle the prefix inside the group/peer variants
Then add the `NoPrefix` feature to the variant itself, which will skip
prefixing any other class in the generated selector (because we already
took care of prefixing `.group` and `.peer`).
We are using an internal symbol such that:
- We can keep it as a private API
- We don't introduce a breaking change
* refactor to simple object instead
We will still use a symbol as an internal/private marker, but the data
itself will be a simple object for now.
If we want to refactor this (and more) in the future using bitflags then
we can refactor that in a separate PR.
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
* Refactor
* Sort based on first occurence of a candidate
This primarily affects components and utilities which contain multiple matched classes
* Simplify
* Update changelog
* Update
* Handle escaped selector characters in parseVariantFormatString
* Escape group names in selectors
Otherwise special characters would break O_O
* Update changelog
* Commit changes to mod time cache all at once
This allows us to track changes in files that are both a context and content dependency in a way that preserves file mod checking optimizations
* fixup
* Add tests
* Refactor
refactor
* Allow `prefixSelector` to take an AST
* Consider multiple formats in `finalizeSelector`
The functions `finalizeSelector` and `formatVariantSelector` together were using a mix for AST and string-based parsing. This now does the full transformation using the selector AST. This also parses the format strings AST as early as possible and is set up to parse them only once for a given set of rules.
All of this will allow considering metadata per format string. For instance, we now know if the format string `.foo &` was produced by a normal variant or by an arbitrary variant. We use this information to control the prefixing behavior for individual format strings.
* Update changelog
* Cleanup code a bit
* fix !imp selector not safelisted as valid class
* add tests for !imp selectors in safelist config
* add test to check for invalid variants
* Only check important utilities for patterns that include a `!`
* Update changelog
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* fix#9655
* update changelog
* add test for making sure calling variantFn doesn't crash
* make it behave as-if modifiers didn't exist
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
This means that if you define your `matchVariant` as:
```js
matchVariant('foo', (value) => '.foo-${value} &')
```
Then you can't use `foo:underline`, if you want to be able to use
`foo:underline` then you have to define a `DEFAULT` value:
```js
matchVariant('foo', (value) => '.foo-${value} &', {
values: {
DEFAULT: 'bar'
}
})
```
Now `foo:underline` will generate `.foo-bar &` as a selector!
* add `context.getVariants`
* use `modifier` instead of `label`
* handle `modifySelectors` version
* use reference
* reverse engineer manual format strings if container was touched
* use new positional API for `matchVariant`
* update changelog
* Add data variant
* Update CHANGELOG.md
Co-authored-by: Jonathan Reinink <jonathan@reinink.ca>
Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
* Rename test variants
* Allow internally negating screens
* Refactor
* Add min/max screen variants
* wip
* Update changelog
* Update tests
* Sort list of variants properly
Technically each test isn’t 100% sorted right in isolation because prettier decisions are basically project-wide. This is close enough though.
* Update tests
* Change `matchVariant` API to use positional arguments
* Fix CS
wip
* Change match variant wrap modifier in an object
Needed for compat w/ some group and peer plugins
* Add modifier support to matchUtilities
* refactor
* Hoist utility modifier splitting
* Rename fn
* refactor
* Add support for generic utility modifiers
* Fix CS
* wip
* update types
* Warn when using modifiers without the option
* Allow modifiers to be a config object
* Make sure we can return null from matchUtilities to omit rules
* Feature flag generalized modifiers
We’re putting a flag for modifiers in front of matchVariant and matchUtilities
* cleanup
* Update changelog
* Properly flag variants using modifiers
* Fix test
* setup for container queries
* remove container query implementation itself
This will be moved to its own plugin.
* update changelog
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* add ability to add a `label`
This could be used for named groups or named container queries in the
future.
* expose `container` to `matchVariant`
Ideally we don't have to do this. But since we will be implementing
`group` and `peer` using the `matchVariant` API, we do require it for
the `visited` state.
* implement `group` and `peer` using the `matchVariant` API
* remove feature flag for `matchVariant`
* update changelog
* use test with non-any type plugin
* choose backgroundSize over backgroundPosition
Ensure that `backgroundColor` can take any value
* add tests to verify fallback plugins
* implement fallback plugins
Whenever an arbitrary value results in css from multiple plugins we
first try to resolve a falback plugin.
The fallback mechanism works like this:
- If A has type `any` and B has type `color`, then B should win.
> This is because `A` will match *anything*, but the more precise type
should win instead. E.g.: `backgroundColor` has the type `any` so
`bg-[100px_200px]` would match both the `backgroundColor` and
`backgroundSize` but `backgroundSize` matched because of a specific
type and not because of the `any` type.
- If A has type `length` and B has type `[length, { disambiguate: true }]`, then B should win.
> This is because `B` marked the `length` as the plugin that should
win in case a clash happens.
* Add any type to a handful of plugins
Needs tests tho
* Add any type to `border-{x,y,t,r,b,l}` plugins
* Add test for any type
* Split on multiple lines
* fixup
* add tests for implicit `any` types
* rename `disambiguate` to `preferOnConflict`
* update tests to reflect `any` types a bit better
* update changelog
* annotate any-type test with a bit more information
Just for future debugging reasons!
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* support `sort` function in `matchVariant`
This will ensure that we can sort arbitrary variant values (and
hardcoded values) to ensure the order.
* update changelog
* Update lockfile
* Tweak formatting
* Refactor content path parsing
* Allow resolving content paths relative to the config file
* Include resolved symlinks as additional content paths
* Update changelog
* Work on suite of tests for content resolution
* reformat integration test list
* Move content resolution tests to integration
* Update future and experimental types
* ignored `undefined` and `null` value values for intellisense
We are not completely ignoring "all" falsey values, because then we
would get rid of `0` values (e.g.: `p-0`) which is not what we want.
* update changelog
* convert the `matchVariant` to look more like `addVariant`
With the biggest difference that the `matchVariant` will have a callback
function that receives the current value of the variant.
* use object as argument for `matchVariant` callback
This will allow us to add more properties in the future if needed
without breaking changes.
- This is a breaking change: `(value) => ...` -> `({ value, other }) => ...`
- This is **not** a breaking change: `({ value }) => ...` -> `({ value, other }) => ...`
* add types for `matchVariant`
* Remove remnants of the user layer
It hasn’t been used in a while
* Rewrite sort offset generation
* wip
* wip
wip
* Handle parasite utilities
* wip
* wip
* Make parallel variants sorting more resillient
It’s not perfect but it’s close
* fix
* remove todo
it adds a new bit so it can’t
* Simplify getClassOrder usage
* Simplify
oops
oops
* Add parasite utility for `dark`
dark mode class name
* Cleanup
* Cleanup
* Simplify
* format files
* Fix prettier plugin to use git build of Tailwind CSS
Symlink and build instead of adding a recursive dev dependency
It breaks node < 16
* Fix prettier error
* wip
* fix test
* Update changelog
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
* Fix issue with returning postcss nodes in addVariant
It’s not a supported use case but it didn’t use to break so let’s just fail silently
* Update changelog
* allow to return an array of format strings from matchVariant or
addVariant
* add parallel variant with function test
* upgrade test to use a function call
* allow to return parallel variants from variant function
Caveat: this now belongs to the same plugin and is not registered as
separate variants which means that sort order can differ.
* prevent crash if `.toMatchFormattedCss()` receives undefined
* update changelog
* ensure that we use a local list of variant functions
Now that a variant function can return a list of variant functions from
within the plugin, we have to make sure to executed and register those
functions as well.
However, we need to make sure that this list is local for the variant
and not "globally" registered otherwise we keep add a dynamic function
to the global list which results in duplicate output becaus multiple
duplicate variants will be registered.
* add little warning regarding potential clashes
* Update CHANGELOG.md
* Fix typo
* Support alpha modifier for theme color values
* Eliminate redundant object creation in resolveFunctionKeys
Building an object of N keys incrementally using Object.reduce + splat results in N intermediate objects. We should just create one object and assign each key.
* Switch to inline theme values in theme fn in config
* Add test case
And fix typos that were definitely not there
* Update changelog
* Add prefers-contrast variants
* add tests for prefers contrast
* dark mode should have precedence over prefers contrast variants
* update changelog
Co-authored-by: Luke Warlow <projects@warlow.dev>
