* WIP
Still need to write error message
* Update error message
first pass at something better
* Detect invalid variant formats returned by functions
* Add proper error message
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* register arbitrary variants
With the new `addVariant` API, we have a beautiful way of creating new
variants.
You can use it as:
```js
addVariant('children', '& > *')
```
Now you can use the `children:` variant. The API uses a `&` as a
reference for the candidate, which means that:
```html
children:pl-4
```
Will result in:
```css
.children\:pl-4 > * { .. }
```
Notice that the `&` was replaced by `.children\:pl-4`.
We can leverage this API to implement arbitrary variants, this means
that you can write those `&>*` (Notice that we don't have spaces) inside
a variant directly. An example of this can be:
```html
<ul class="[&>*]:underline">
<li>A</li>
<li>B</li>
<li>C</li>
</ul>
```
Which generates the following css:
```css
.\[\&\>\*\]\:underline > * {
text-decoration-line: underline;
}
```
Now all the children of the `ul` will have an `underline`. The selector
itself is a bit crazy since it contains the candidate which is the
selector itself, it is just escaped.
* add tests for arbitrary variants
This still requires some work to the `defaultExtractor` to make sure it
all works with existing code.
* update changelog
* Fix candidate detection for arbitrary variants
* Refactor
* Add support for at rules
* Add test for attribute selectors
* Fix test
* Add attribute selector support
* Split top-level comma parsing into a generalized splitting routine
We can now split on any character at the top level with any nesting. We don’t balance brackets directly here but this is probably “enough”
* Split variants by separator at the top-level only
This means that the separator has to be ouside of balanced brackets
* Fix extraction when using custom variant separators
* Support custom separators when top-level splitting variants
* Add a second multi-character separator test
* Split tests for at-rule and at-rule with selector changes
* Add nested at-rule tests
* Fix space-less at-rule parsing in addVariant
* Add test for using with `@apply`
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
* Add failing test cases
* Flatten finalizeSelector code
* Use AST operations to format selector classes
With this change we only parse the selector once and operate on the AST until we need to turn it back into a selector. In addition this lets us solve an issue where .replace(…) did the wrong thing because it doesn’t understand that .base and .base-foo are two different classes
* Remove extraneous, non-matching selectors from utilities
* Update changelog
* Only check selectors containing base apply candidates for circular dependencies
When given a two rule like `html.dark .a, .b { … }` and `html.dark .c { @apply b }` we would see `.dark` in both the base rule and the rule being applied and consider it a circular dependency. However, the selectors `html.dark .a` and `.b` are considered on their own and is therefore do not introduce a circular dependency.
This better matches the user’s mental model that the selectors are just two definitions sharing the same properties.
* Update changelog
* Handle duplicate atrules without children
We assumed that all At Rule nodes had children. Including ones that do not and should not — for example `@import url(…);`. Since this is not the case we’ll skip adding children for nodes that don’t have any.
* Update changelog
Co-authored-by: Jordi Marimon Palarea <jordimarimon7@gmail.com>
* ensure the `percentage` data type is validated correctly
When checking for our data types, we have to make sure that each part is
correct, this wasn't happening for the `percentage` data type, which
meant that `top_right_50%` was a valid percentage value because it ended
in `%` which is not correct.
Because of this, the generated code was non-existent because we got a
warning:
The class `bg-[top_right_50%]` is ambiguous and matches multiple utilities.
Use `bg-[length:top_right_50%]` for `background-size: top right 50%`
Use `bg-[position:top_right_50%]` for `background-position: top right 50%`
If this is content and not a class, replace it with `bg-[top_right_50%]` to silence this warning.
But this is not correct because this can never be a valid background
size due to the `top right` section.
This fixes it by validating each part individually, and now we get
generated css.
* update changelog
* fix: allow extraction from template literal with array
* fix: support extraction from array in function
* test: add more tests for function and template
* test: add test for dynamic classes
* test: add dynamic class test in js
* test: add dynamic class test in js single quote
* Cleanup a bit
* Update changelog
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* Add prefix alone to animation names. Fixes#7149.
* Add test for keyframe animations with a dot in the name
* Add test for prefixed version
* Fix CS
* Simplify
* Update changelog
* Fix
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* Only add `!` to selector class matching template candidate
Fixes#7226.
Before this PR, if you had a class like:
```css
.one .two {
background: black
}
```
...and then used `!one` in your template, the generated CSS would be this:
```css
.\!one .\!two {
background: black !important
}
```
This would cause the styles to not be applied unless you also added `!` to the beginning of other classes in the template that are part of this selector.
This PR makes sure that other classes in the selector aren't mistakenly prefixed with `!`, so that you can add `!` to only one of the classes in your template and get the expected result.
* Update CHANGELOG
* Fix context reuse test
* Don't update files with at-apply when content changes
* Prevent at-apply directives from creating new contexts
* Rework apply to use local postcss root
We were storing user CSS in the context so we could use it with apply. The problem is that this CSS does not get updated on save unless it has a tailwind directive in it resulting in stale apply caches. This could result in either stale generation or errors about missing classes.
* Don’t build local cache unless `@apply` is used
* Update changelog
* Preserve source maps for `@apply`
* Overwrite the source for all cloned descendants
* Preserve source maps when expanding defaults
* Verify that source maps are correctly generated
* Update changelog
* Prevent nesting plugin from breaking other plugins
This uses a private API but it’s the only solution we have right now. It’s guarded to hopefully be less breaking if the API disappears.
* Update changelog
This would be better as a symbol but the stringy-ness of class candidates is fairly well baked into assumptions across the codebase. Using `new String` with a well placed check seems to solve the problem.
* add prettier-plugin-tailwindcss
This will use the prettier plugin in our tests as well, yay consistency!
* ensure that both `group` and `peer` can't be used in `@apply`
This was only configured for `group`
* expose `sortClassList` on the context
This function will be used by the `prettier-plugin-tailwindcss` plugin,
this way the sorting happens within Tailwind CSS itself adn the
`prettier-plugin-tailwindcss` plugin doesn't have to use internal /
private APIs.
The signature looks like this:
```ts
function sortClassList(classes: string[]): string[]
```
E.g.:
```js
let sortedClasses = context.sortClassList(['p-1', 'm-1', 'container'])
```
* update changelog
* add sort test for utilities with the important modifier e.g.: `!p-4`
* Add failing tests for negative utility detection
We're not generating them properly in all cases, when using at-apply we sometimes crash, and safelisting doesn't currently work as expected.
* Refactor
* Generate utilities for negatives before and after the prefix
* Properly detect negative utilities with prefixes in the safelist
* Refactor test a bit
* Add class list tests
* Update changelog
* quick fix for incorrect arbitrary properties
Turns out that using links like [https://example.com] causes arbitrary
properties to generate invalid css.
This is a very dirty quick fix for this specific case, so we have to fix
this properly!
* update changelog