* WIP
* use `parse` instead of `defaultExtractor`
* skip `Vue` describe block
* add a few more dedicated arbitrary values/properties tests
* use parallel parsing
* splitup Vue tests
* add some Rust specific tests
* setup parse candidate strings test system
These tests will run against the `Regex` and `Rust` based parsers. We
have groups of classes of various shapes and forms + variants and
rendered in various template situation (plain, html, Vue, ...)
+ enable all skipped tests
* ensure we also validate the classes with variants
The classes with variants are built in the `templateTable` function, so
we get them out again by using the potional arguments of the `test.each`
cb function.
* cleanup test suite
* add "anti-test" tests
To make sure that we are _not_ parsing out certain values given a
certain input.
* Add ParseAction enum
* Restart parsing following an arbitrary parse failure
* Split variants off before validating the uility part
* Collapse candidate from the end when validation fails
* Support `<`, and `>` in variant position
* fix error
* format parser.rs
* Refactor
* Update editorconfig
* wip
* wip
* Refactor
* Refactor
* Simplify
* wip
* wip
* wip
* wip
* wip
* wip
* wip
* run `cargo clippy --fix`
* run `cargo fmt`
* implement `cargo clippy` suggestions
These were not applied using `cargo clippy --fix`
* only allow `.` in the candidate part when surrounded by 0-9
This is only in the candidate part, not the arbitrary part.
* % characters can only appear at the end after digits
* > and < should only be part of variants (start OR end)
It can technically be inside the candidate when we have stacked
variants:
```
dark:<sm:underline
dark:md>:underline
```
* handle parsing utilities within quotes, parans or brackets
* mark `pt-1.5` as an expected value sliced out from `["pt-1.5"]`
* Add cursor abstraction
* wip
* disable the oxideParser if using a custom `prefix` or `separator`
* update tests
* Use cursor abstraction
* Refactor more code toward use of global cursor
* wip
* simplify
* Simplify
* Simplify
* Simplify
* Cleanup
* wip
* Simplify
* wip
* Simplify
* Handle candidates ending with % sign
* Tweak code a bit
* fmt
* Simplify
* Add cursor details to trace
* cargo fmt
* use preferred `zoom-0.5` name instead of `zoom-.5`
* drop over-extracted utilities in oxide parser
The RegEx parser does extract `underline` from
```html
<div class="peer-aria-[labelledby='a_b']:underline"></div>
```
... but that's not needed and is not happening in the oxide parser
This means that we have to make the output check a little bit different
but they are explicit based on the feature flag.
* allow extracting variants+utilities inside `{}` for the oxide parser
* characters in candidates such as `group-${id}` should not be allowed
* do not extract any of the following candidate `w-[foo-bar]w-[bar-baz]`
* ensure we can consume the full candidate and discard it
* Add fast skipping of whitespace
* Use fast skipping whenever possible
* Add fast skipping to benchmark
* Hand-tune to generate more optimized assembly
* Move code around a bit
This makes sure all the fancy SIMD stuff is as early as possible. This results in an extremely minor perf increase.
* Undo tweak
no meaningful perf difference in real world scenarios
* Disable fast skipping for now
It needs to be done in a different spot so it doesn’t affect how things are returned
* Change test names
* Fix normalize config error
* cleanup a bit
* Cleanup
* Extract validation result enum
* Cleanup comments
* Simplify
* Fix formatting
* Run clippy
* wip
* add `md>` under the special characters test set
---------
Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* 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>
* 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>
* 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>
* 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`.
2021-09-03 13:48:16 +02:00
Renamed from tests/jit/animations.test.js (Browse further)
