The main things I'm seeing right now are:
1. Some selectors are broken up into multiple selectors, especially when
there are pseudo classes involved where the output is unknown. For
example `::ng-deep, ::v-deep {}` will be split into `::ng-deep {},
::v-deep {}`
2. It looks like a lot of selectors were dropped, however after looking
at them in more detail I noticed that they were _duplicated_ before.
This means that now the output will be smaller in these cases!
* exclude `Features.LogicalProperties` lightningcss feature
We don't want this to automatically apply since we have dedicated
logical property based utilities already.
We also have a feature flag to toggle some utilities to make use of
logical property based ones.
This feature should be opt-in to prevent backwards compatibility (e.g.:
RTL sites that _did_ use a mr-4 explicitly).
* update default browserslist
* explicitly include/exclude Lightning CSS features
* update tests based on new browserslist and include/exclude features from Lightning CSS
* update integration tests
* prefer user browserslist, fallback to built-in browserslist
* always include Nesting
If a custom browserslist config is used, then we don't explicitly set
the include/exclude features from Lightning CSS (except for nesting, we
always want to process nesting)
* ensure to fallback to the current working directory
* update changelog
* bump `lightningcss`
* allow for non-standard selector combinators such as `::deep`
* just use Prettier when comparing CSS results
We were using 2 different engines where the stable one was not using
Lightning CSS and the Oxide one was using Lightning CSS.
To ensure that we didn't have to rewrite every single test expectation,
the `toMatchFormattedCss` parsed both the actual and expected value
using Lightning CSS (to make the result similar), then it used Prettier
to make it... pretty.
Right now we _only_ use Lightning CSS, which means that we can drop the
additional lightningcss format step and just use Prettier on both the
actual and expected values.
Pretty also only prettifies the CSS, it doesn't rewrite it. E.g.:
`@media (min-width: 768px)` will not be optimized to `@media (width >=
768px)`, that's something that Lightning CSS does for us.
This will require some changes in our test output, but it will be
consistent afterwards because there won't be hidden transformation steps
anymore. Because up until now it could be that the actual result was
`color: black` but the tests showed `color: #000` (because it is
shorter).
This change will reflect reality.
* update tests based on previous commit
* only use `toMatchFormattedCss` instead of `toMatchCss`
They both do the exact same thing right now. While `toMatchCss` is
shorter, `toMatchFormattedCss` makes a bit more sense since we are
comparing the Prettier results.
* update integration tests
* Simplify CI, make oxide engine the default (#11281)
* remove integration tests for the `stable` engine
* make `integration-tests-oxide` the default integration tests workflow
* remove unnecessary CACHE_PREFIX
* drop `ci-stable.yml` workflow
* make `CI — Oxide` the default
+ drop testing against 3.3 branch (since this is stable only)
+ remove unnecessary CACHE_PREFIX
* drop `release-insiders-stable.yml` workflow
* make `Release Insiders — Oxide` the default
+ change release channel to just `insiders` instead of `oxide-insders`
* drop 3.3 branch from integration tests
* change job name for insiders release
This makes it consistent with the other job names
* prep `release-oxide.yml` workflow to be the default workflow
* add Tailwind Play update
Currently commented out until we figure out how this will work exactly.
* use `env.VERSION` for the version we want to release
* drop `release-stable.yml` workflow
* make `release-oxide.yml` the default `release.yml` workflow
* inline "Calculate environment variables" step
* cache node_modules and cargo related files/folders in the release step
* always use the default CLI
* drop oxide specific implementation
* ensure we test `--postcss` in the CLI
Even for the Oxide engine
* always process `@import` rules
* remove `generalizedModifiers` flag
This was already enabled by default. This commits removes some of the
outstanding references to it.
* remove built-in peer dependencies for the CLI
* drop unused esbuild dependency
* fix type for `configBag`
* setup Lightning CSS for the CLI
* drop `cssnano` dependency
We only used this in the CLI and we now use Lighting CSS which has this
built in already. Therefore we can get rid of this as a dependency.
* ensure `imported.css` file exists in integration tests
* passthrough `options` to lightningcss
Ideally we can read this from `result.map` instead. However this doesn't
get filled in for whatever reason even though we use `map: {inline:true}`.
You can run the `tests/cli.test.js`, and more specifically the
`--postcss supports process options with custom config` test.
* Always process CSS with Lightning CSS
Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning.
* Remove code for normalizing `@import "tailwindcss/*"` statements
* ensure tailwind doesn't crash when a `tailwind.config.js` file is not present
* add `log.group` to group multiple messages together with different types
* remove engine specific checks in integration tests
* remove unused imports/variables
Make linting check happy
* support `content: ['auto']`
This will allow us to still use auto content detection, but since this
is part of the `content` array, it also allows you to add custom paths
if you want.
E.g.:
```js
content: ['auto', './node_modules/my-library/*.{jsx,tsx}']
```
* ensure `content.files` is always an array
This allows us to simplify some checks because 'auto' will now be part
of the array instead of checking if `content.files` is auto or if it is
an array containing 'auto'.
* fix tests, ensure default config is not injected
* simplify `auto` normalization
* always use the defaultFullConfig
No need to override the defaultFullConfig with `{content: 'auto'}`
because this will be included in the default config already.
* drop condition which ensured `files` was an empty array
This is not needed anymore because when `content` is omitted it behaves
as if it was set to `auto`.
* drop removal of `content`
We used to remove the `content` from the actual configuration files when
using `tailwindcss init` for the oxide engine. This was to ensure that
`auto content detection` was used instead (by default).
But now it is always enabled by default therefore this is not needed
anymore.
* ensure setting `content: 'auto'` works
* improve file cache handling
We have to make sure that we get into the previous state whenver a test
is done.
We were using some `!fileCache[filePath]` checks, however we also used
`null` as a sentinel value when something wasn't found. But, `null` is
falsey as well so some checks where incorrect.
Using a dedicated value and a `Map` makes this safer and more correct
because we can now use `.has()`.
* drop `cleanupFile`, `removeFile` will already take care of it
* drop oxide check in `resolvedChangedContent`
At this point the `context.tailwindConfig.content.files` is already
fully resolved regardless of the engine we are in.
* refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag
* use feature flag for sorting classes
Once the Oxide engine is the default default, then we can drop this
entirely because the result from the Rust parser will already be sorted.
* drop `crosscheck` from tests where it is safe
First pass of deleting `crosscheck`. These are all the places where we
didn't have any differences between the Oxide and Stable engine.
* replace `__OXIDE__` in corePlugins with feature flag
* use `globalThis.__OXIDE__ ?? false`
This will ensure that in places where we don't have `__OXIDE__` that we
can still properly fallback to `false`.
* use `flex` as the go-to utility when testing features
* prefer `space-utilities` tests instead of `oxide` test
* drop crosscheck check
Since the `oxideParser` is disabled by default, all the tests can use
the `stable` output.
* use simple `false` default values for feature flag defaults
* drop `__OXIDE__` injections in build scripts
* use stable `flex` and `z-{...}` utilities instead of color utilities
flex and z-index related utilities are more stable than the color
utilities right now because the color utilities will use a raw color
value or a combination with a css variable depending on a feature flag.
* drop unused `ENGINE` environment variable
* drop stable engine manifest files
* drop `swap-engines` tooling
---------
Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
* Don’t move `::deep` pseudo element to end of selector when using `@apply`
* Update changelog
* Move pseudo-elements in two passes
* Rewrite pseudo-element relocation logic
* Update test
`::test` is an unknown pseudo element and therefore may be actionable _and_ nestable
* Add tests
* Simplify tests
* Simplify
* run tests on CI multiple times
This works around the timeouts/flakeyness of GitHub Actions
* Update formatting
* Add comment
* Mark webkit peusdo elements as terminal
* update comment
* only execute the `global-setup` once
* Simplify
NO SORT FN YAY
* Use typedefs
* Update changelog
* Update changelog
* update again
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
* Pull pseudo elements outside of `:is` and `:has` when using `@apply`
* Update changelog
* Refactor
* Update important selector handling for :is and :has
* fixup
* fixup
* trigger CI
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
* Use `:is` to make important selector option insensitive to DOM order
* WIP
* add `applyImportantSelector` helper
* use new `applyImportantSelector`
* update tests
* remove unnecessary slice adjustment
Not 100% sure.
* update changelog
---------
Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
* Make `dark` and `rtl`/`ltr` variants insensitive to DOM order
* Add explicit test for stacking dark and rtl variants
* Update changelog
---------
Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
* disable color opacity plugins by default for the `oxide` engine
* update tests to reflect this change in the `oxide` engine
* update changelog
* reflect changes in integration tests
* drop empty lines when diffing output
* replace expected css with optimized lightningcss output
Lightning CSS generates a more optimal CSS output.
Right now the tests are setup in a way that both the generated css and
expected css are run through `lightningcss` to make sure that the output
is concistent for the `stable` and `oxide` engines. But this also means
that the expected output _could_ be larger (aka not optimized) and still
matches (after it runs through lightningcss).
By replacing this with the more optimal output we achieve a few things:
1. This better reflects reality since we will be using `lightningcss`.
2. This gets rid of unnecessary css.
3. Removed code!
* Run test suite against both engines
* make eslint happy
* only run `stable` tests on Node 12
* use normal expectation instead of snapshot file
When we run the tests only against `stable` (for node 12), then the
snapshots exists for the `Oxide` build. They are marked as `obsolete`
and will cause the `npm run test` script to fail. Sadly.
Inlined them for now, but ideally we make those tests more blackbox-y so
that we test that we get source maps and that we can map the sourcemap
back to the input files (without looking at the actual annotations).
* properly indent inline css
Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
This will reduce the amount of different test "implementations" and
should further unify/normalise the tests. Some tests are very large and
can be split up more but this is a start in the right direction.
One of the biggest benefits is that changes in the tests file re-trigger
a jest run in watch mode. A change in the HTML/CSS file won't.
* Fix application of rules with multiple matches of differing selectors
`-foo-1` and `foo-1` are both matches for the class `-foo-1` but `@apply` only wants the first one. It would remove the second one and cause an error because it’s an entirely separate match that had it’s only rule removed.
* 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 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
* 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`
* 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
* 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
* ensure apply of rule inside atrule works
If that atrule happens to contain another rule that is technically
unrelated.
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* update changelog
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* only generate variants for non-user layers
If you have the following css:
```css
@tailwind utilities;
.foo {
color: red;
}
```
And you HTML looks like this:
```html
<div class="hover:foo"></div>
```
Then the output should _not_ generate a `.hover\:foo {}` class.
* ensure that you can apply user csss (without variants)
* update changelog
* add `collapseDuplicateDeclarations`
This will allow us to remove duplicate declarations. This occurs when
you are using `@apply` for example.
The reason I implemented it as a separate step, is because this doesn't
only happen for `@apply`, but it also happens if you do something like:
```js
addComponents({ '.btn-blue, .btm-red': { padding: '10px' } })
```
So instead of tracking down every place this is happening, it now
happens at the very end.
* use new plugin in processTailwindFeatures
* add/update tests by removing duplicate declarations
* update changelog
* Replace `culori` with simple color parser
* Use space-separated color syntax
* Update default color values to use space-separated syntax
* Update separator regex
* Fix tests
* add tests for the new `color` util
Also slightly modified the `color` util itself to take `transparent`
into account and also format every value as a string for consistency.
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
* support `@apply` for classes outside of a `@layer`
* Add failing test for respecting source order
* sort rules when using `@apply`
The `layer` was not taken into account yet when we resolved the rules
from the applyCache. This is because we set the `classCache` to the
`matches` inside of the `generateRules` function. You can think of them
as "raw" rules I guess. However, it is later in that function that we
apply the `layerOrder` to the `sort`.
This does mean that when you `@apply font-bold text-red-500` that the
rules inside the `.target {}` will be in order of the "normal" css as
well.
Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
* move `./tests/jit` to `./tests`
* make tests consistent
Abstracted a `run` function and some syntax highlighting helpers for
`html`, `css` and `javascript`.
