* partition nodes as soon as possible
Time to write another story on `@apply`...
When we write code like this:
```css
.a {
@apply b;
}
.b {
@apply uppercase;
color: red;
}
```
Then we create 2 Nodes in our context to keep track of. One has
identifier `a`, the other has identifier `b`. However, when we have an
`@apply` and it contains multiple declarations/atrules, then we have to
split up the (aka partition) node into multiple nodes so that we can
guarantee the correct expected sort order.
This means that the above example technically looks like this:
```css
.a {
@apply b;
}
.b {
@apply uppercase;
}
.b {
color: red;
}
```
If this was your input, then we would still have 1 node for identifier
'a', but we would have 2 nodes for identifier 'b'.
As mentioned earlier, this is important to guarantee the correct order,
here is an example:
```css
.b {
@apply md:font-bold xl:font-normal; /* Here we can sort by our
internal rules. This means that the `md` comes before `xl`. */
}
```
... however
```css
.b {
@apply xl:font-normal; /* This now exists _before_ the example below */
}
.b {
@apply md:font-bold; /* Because we respect the order of the user's css */
}
```
So to guarantee the order when doing this:
```css
.b {
@apply xl:font-normal;
@apply lg:font-normal;
}
```
We also split this up into 2 nodes like this:
```css
.b {
@apply xl:font-normal;
}
.b {
@apply lg:font-normal;
}
```
The tricky part is that now only 1 empty `.b` node exists in our context
because we partitioned the orginal node into multiple nodes and moved
the children to the new nodes and because they are new nodes it means
that they have a different identity.
This partitioning used to happen in the expandApplyAtRules code, but
this is a bit too late because the context has already been filled at
this time. Instead, we move the code more to the front, as if you wrote
those separated blocks yourself. Now the code to inject those nodes into
the context happens in a single spot instead of multiple places.
Another good part about this is that we have better consistency between
each layer because it turns out that these two examples generated
different results...
```css
.a {
@apply b;
}
.b {
@apply uppercase;
color: red;
}
```
... is different compared to:
```css
@tailwind components;
@layer components {
.a {
@apply b;
}
.b {
@apply uppercase;
color: red;
}
}
```
Even if both `a` and `b` are being used in one of your content paths...
Yeah.. *sigh*
* add more `@apply` related tests
* update changelog
* remove support for basic nesting (leftover)
* remove leftover todo
This has been fixed already
* improve extractCandidates
When we have a css rule that is defined as `.foo, .bar {}`, then we will
crawl each selector and link it to the same node. This is useful because
now our Map looks something like this:
```js
Map(2) { 'foo' => Node {}, 'bar' => Node {} }
```
This allows us to later on `@apply foo` or `@apply bar` and we can do a
direct lookup for this "candidate".
When we have css defined as `span {}`, then we consider this
"non-ondemandable". This means that we will _always_ inject these rules
into the `*` section and call it a day.
However, it could happen that you have something like this: `span, .foo
{}` up until now this was totally fine. It contains a non-ondemandable
selector (`span`) and therefore we injected this into that `*` section.
However, the issue occurs if you now try to `@apply foo`. Since we had
an early return for this use case it didn't endup in our Map from above
and now you get an error like:
```
The `foo` class does not exist. If `foo` is a custom class, make sure it
is defined within a `@layer` directive."
```
So instead what we will do is keep track whether or not a css rule
contains any on-demandable classes. If this is the case then we still
generate it always by putting it in that `*` section. However, we will
still register all on-demandable classes in our Map (in this case `.foo`).
This allows us to `@apply foo` again!
* update changelog
* ignore content files that don't exist
PostCSS CLI will give you a fake file path that ends in /stdin if you
are reading from stdin.
* update changelog
* use outputFile instead of direct writeFile
This is an improvement we introduced earlier but forgot this part.
* allow to pipe in data to the CLI
* add integration tests to validate piping to the CLI
* update changelog
* fix(cli): avoid write same output when no changes
* generalize outputFile
This function will check a cache, it will only write the file if:
- The modified timestamps changed since last time we wrote something.
This is useful to know if something changed by another tool or
manually without diffing the full file.
- The contents changed.
* further simplify checks
Turns out that reading files and comparing them is fairly fast and there
is no huge benefit over only using the Stats of the file and keeping
track of that information.
Thanks @kentcdodds!
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
* Always include css with apply in context
* Use let
We use it more consistently
* Remove early return
To match the style of the surrounding code
* Don't return layer directives
They do not need to be returned here. If it's needed in the future its easy enough to add it back.
* Use let
* Update changelog
* fix typo
And re-format comments
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
* improve collapsing of duplicate properties
In theory, we don't have to do anything because the browser is smart
enough to figure everything out. However, leaving in duplicate
properties is not that ideal for file size.
Our previous method was pretty simple: if you see a declaration you
already saw in this rule, delete the previous one and keep the current
one.
This works pretty well, but this gets rid of **all** the declarations
with the same property. This is not great for overrides for older
browsers.
In a perfect world, we can handle this based on your target browser but
this is a lot of unnecessary complexity and will slow things down
performance wise.
Alternative, we improved the solution by being a bit smarter:
1. Delete duplicate declarations that have the same property and value
(this will get rid of **exact** duplications).
2. Delete declarations with the same property and the same **unit**.
This means that we will reduce this:
```css
.example {
height: 50%;
height: 100px;
height: 20vh;
height: 30%;
height: 50px;
height: 30vh;
transform: var(--value);
transform: var(--value);
}
```
To:
```diff-css
.example {
- height: 50%; /* Another height exists later with a `%` unit */
- height: 100px; /* Another height exists later with a `px` unit */
- height: 20vh; /* Another height exists later with a `vh` unit */
height: 30%;
height: 50px;
height: 30vh;
- transform: var(--value); /* Value is too complex, but is **exactly** the same as the one below */
transform: var(--value);
}
```
This will reduce the values that we are 100% sure that can be safely
removed. This will still result in some overrides but the browser can
handle those for you.
Fixes: #6844
* update changelog
