* 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>
* 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>
* 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>
* use String.raw for css escapes
This will allow us to write code like:
```css
.mobile\:font-bold {}
```
Instead of
```css
.mobile\\:font-bold {}
```
Which resembles "real" css way better in our tests.
* use String.raw in integration tests as well
* move `./tests/jit` to `./tests`
* make tests consistent
Abstracted a `run` function and some syntax highlighting helpers for
`html`, `css` and `javascript`.
