* 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
* Fix intellisense for plugins with multiple `@apply` rules
Intellisense uses `expandApplyAtRules` directly and doesn’t partition them. When a plugin registers components using something like `”@apply flex”: {}` more than once in the same component intellisense will break. This isn’t a problem for Tailwind CSS proper because we do rule partitioning. Given that Intellisense is using it directly though we shouldn’t outright break in the face of this situation even if the result isn’t 100% accurate (the source maps won’t be correct in this case).
* Update changelog
Co-authored-by: psucoder <hungle.info@gmail.com>
* 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
* allow for arbitrary configuration in the `theme` section
This is useful for third party plugins otherwise you will get an error.
* WIP: `theme()` utility function code completion
This will give you code completion in the `theme()` function. The reason
it is still a WIP is that this only works with the default config right
now and not 100% sure if it is possible to define generics in JSDoc.
The idea would be to:
- Provide types from the default config
- Provide types from the custom config (e.g.: 3rd party plugin)
- Override default config types with the overrides of the user's config
Right now this only provides types for the defaultConfig which might
result in dropping all of this in favor of a much simpler:
```ts
theme<D = any>(path: string, defaultValue: D) => D
```
But this sadly doesn't give you "nice" auto completion. However, the
default might be good enough if we don't error on for example
`theme('customPlugin')` which is currently not the case.
* update changelog
* undo all `theme` types, and type it as `theme(path: string): any`
Since currently we don't want to investigate time to make the code
completion *perfect* (because it might be even impossible to do it
properly due to resolving of overrides, extend and deeply nested presets)
For now we will provide a way simpler type, which is better than
incorrect types. So far we only had types for the default config theme
*only*.
