* parse the `calc()`-like expressions and format them
* update changelog
* Add test case for double negatives
wanted to be sure this worked
---------
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
When you have a custom config for the prefix/separator values, then we
want to disable the `oxideParser` for now. But we also have to ensure
that if you use the value `"all"` for the experimental feature flag that
we enable all feature flags.
We were using the keys of the array instead of the values.
* make main plugin async
This way we can improve the `fs.readFileSync` to a bunch of
`fs.promises.readFile` in a `Promise.all` instead.
* make CLI plugin async
* update CHANGELOG
* Refactor
* Sort based on first occurence of a candidate
This primarily affects components and utilities which contain multiple matched classes
* Simplify
* Update changelog
* Update
* Refactor
* Don’t prefix classes in arbitrary values for group and peer
* use `foo` instead of `lol`
* handle the prefix inside the group/peer variants
Then add the `NoPrefix` feature to the variant itself, which will skip
prefixing any other class in the generated selector (because we already
took care of prefixing `.group` and `.peer`).
We are using an internal symbol such that:
- We can keep it as a private API
- We don't introduce a breaking change
* refactor to simple object instead
We will still use a symbol as an internal/private marker, but the data
itself will be a simple object for now.
If we want to refactor this (and more) in the future using bitflags then
we can refactor that in a separate PR.
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
* always prepend the Tailwind License
Even when you are not using preflight.
* drop the Tailwind License from the preflight plugin
* drop the license in the tests
This allows us to focus on the actual generated CSS without the license.
The license also includes the version number which we would have to
update every time we release a new version.
* update the source maps snapshots
* always prepend the license when using the CLI
* update Tailwind CLI integration test
* use `defaults` for `browserslist`
+ some features that we require for Tailwind to work.
* simplify Lightning CSS features
Always transpile `Nesting`, never transpile `LogicalProperties`.
* bump caniuse-lite (`npx browserslist@latest --update-db`)
* reflect changes in the tests
* update changelog
* 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
* add failling test using array syntax without space delimiter
* add Rust test with candidates in array without spaces
* Fix JS arrays without spaces
* make the `oxideParser` the default
* sync feature flags with reality
* use better example in tests to be more real
* skip failing tests in the RegEx parser
* update changelog
* make `clippy` happy
---------
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* 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>
* 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
* handle custom `transformer` and `extractor` implementations
Right now the Rust based parser can't work with custom `transfomers` or
`extractors`.
In a perfect world we can implement as many custom parsers/extractors in
Rust such that we don't need this at all. In an almost perfect world we
can pass the transformer and extractor to the Rust based parser and call
the callback functions to handle all of this. This is probably what we
are going to do in the future but this requires more work to make sure
that:
1. It works as expected
2. Doesn't result in (major) performance issues
Since it currently doesn't work with the Rust based parser, we can
implement a fix for this in the meantime before we reach the "perfect"
solution.
One solution to this problem is to check if we do have a custom
transformer or a custom extractor and if we do, then we can bail on the
Rust parser completely and just use the current regex based parser.
An alternative solution, the solution implemented here, is that we group
the `changedContent` into 2 buckets. The bucket where we rely on the
default transformer and extractor and a bucket where a custom
transformer or extractor is used.
Then, the bucket where we use the default transformer and extractor can
still rely on the way faster Rust based parser. For the other bucket we
fallback to the regex based parser.
The nice part about this is that we can use both parsers at the same
time, and the majority of the use cases should use the faster Rust based
parser.
* update changelog
* only try to pretty print `err.source` if it exists
* fix small typo
* drop unnecessary path resolving
* add `from` and `to` to `run` test helper
* enable all source map tests
* ensure source maps are generated properly
* update annotation values in tests
* handle `map: true`
* add test for `map: { inline: true }`
* force Lightning CSS to handle an inline source map
* base64 encode the test name
This will get rid of special characters that can cause issues /
confusion when debugging tests.
* ensure utilities and components with variants are pointing to the correct source
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* update changelog
---------
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* Add `has-*` variants for `:has(...)` pseudo-class
* Update changelog
* Fix mistake in test
---------
Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
* enable `--no-autoprefixer` test
* handle `--no-autoprefixer` using lightningcss
* bump default chrome version for lightningcss plugin
* handle `map` being nullable
* add `--no-autoprefixer` test including nesting
* set Chrome to version 111 as a default value
* resolve the output message when resolving the promise
* deprecate `--no-autoprefixer` for the CLI
* update changelog
* 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>
* run PostCSS relative to test file
The PostCSS `from` was always set to the `tests/util/run` file with the
current test name as a query param to make it unique. However, that
results in issues with relative file paths because they are now relative
to this file instead of the actual test file.
Luckily, `expect.getState()` exposes the `testPath` value that points to
the current test file itself.
* add built in `@import` processing
+ additional features such that you can use `@tailwind` and `@config`
directives before the `@import` at rule which isn't normally allowed.
However "@tailwind" in a way is an `@import` and `@config` in a way is
a `@charset` which can be used before the `@import` at rule.
* drop partial normalizeTailwindDirectives when in the Oxide engine
This will now be handled by Tailwind from a higher level, so the core
doesn't have to worry about normalizing this anymore since it will
always be normalized right now.
* add `handleImportAtRules` to CLI
* update changelog
* scope `import processing` to the oxide engine
* update Changelog
* use direct comparison
We don't need the `startsWith` check anymore because the contents of the
comment will be the actual value we expect.
* resolve all _existing_ content paths
* pin `@napi-rs/cli`
* WIP: Log all resolved content files/globs
* only filter out raw changed content in non-auto mode
* skip parseCandidateFiles cache in `auto` mode
* improve algorithm of detecting content paths
1. Files in the root should be listed statically instead of using globs.
2. Files and folders in special known direct child folders should be
listed statically instead of using globs (e.g.: `public`). This is
because these special folders are often used to store generated AND
source files at the same time. Using globs could trigger infinite
loops because we are watching and acting upon dist files.
3. All file extensions found in the project, should be used in the globs
in addition to a known set of extensions.
4. Direct folders seen from the root, can use the glob syntax
`<root>/src/**/*.{...known-extensions}`
* inline wanted-extensions
Not 100% convinced yet, but seems cleaner so far.
* ensure writing an file also makes the parent folder(s)
* add integration tests for the auto content feature
* add pnpm and bun lock files
* Revert "inline wanted-extensions"
This reverts commit 879c1248524e84216125f4a24e0160b40736333a.
* sort binary-extensions and add lockb
* sort + add `lock` to ignored extensions
* drop `yarn.lock`, because lock extensions are already covered
* group template extensions
This will make it a bit easier to organize in the future.
* drop empty lines and commented lines from template-extensions
* skip the config path when resolving template files
The config file will automatically trigger a rebuild when this file is
changed. However, this should not be part of the template files because
that could cause additional css that's not being used.
* make `auto content` the default in the oxide engine
- In the oxide engine, the default `content: []` will be dropped from
the default configuration (config.simple.js, config.full.js).
- If you have `content: []` or `content: { files: [] }` then the auto
content feature won't be active. However if those arrays are empty a
warning will still be shown. Adding files/globs or dropping the
`content` section completely will enable auto content.
* only test the auto content integration test in the oxide engine
* set `content.files` to `auto` instead of using `auto: boolean`
This way we don't run into the issue where the `config.content.files` is
set and the `config.content.auto` is set to true.
* drop log
* ensure we validate the config in the CLI
* show experimental warning for automatic content detection
* use cached version of the getCandidateFiles instead of bypassing it
* use `is_empty()` shorthand
Thanks, Clippy!
* add test to ensure nested ignored folders are not scanned
* add `tempfile` for tests
* add auto content tests in Rust
* refactor auto content detection
This will also make sure that if we have (deeply) nested ignored
folders, then we won't use deeply nested globs (**/*.{js,html}) for the
parent(s) of the nested ignored folders but instead use a shallow glob
for each directory (*/*.{js,html}).
Then each sibling directory of the parent can use deeply nested globs
again except for the direct parent.
* use consistent comments
* ensure ignored static listed files are not present
* improve performance by ~30x
On a big test project this goes from ~6s to ~200ms
* improve performance by ~5x
We started with a ~6s duration
Then in the previous commit, we improved it by ~30x and it went down to
~200ms
Now with this change, it takes about ~40ms. That's another ~5x
improvement.
Or in total a ~150x improvement.
* ensure nested folders in `public/` are also explicitly listed
* add shortcut for normalizing files
This is only called once so won't do anything to the main performance of
Tailwind CSS. But always nice to make small performance improvements!
* run Rust tests in CI
* fix lint warnings
* update changelog
* Update CHANGELOG.md
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
* Refactor
* Don’t resolve functions for anything not using theme or screen
* Normalize math operators inside calc when handling functions
* Inline postcss-value-parser
* Treat all functions the same as calc
* Remove workaround for calc + operators without spaces
* Remove `postcss-value-parser` dependency
* Update lockfile
* Update sourcemaps
* Update changelog
* Update `value-parser` formatting
* Stop prettier from complaining
* disable useragent styling for dialog
* nits
* Update src/css/preflight.css
* Simplify dialog reset
We don’t want to reset everything here. Just the padding should be enough.
* Update test
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* Make font settings propagate into buttons, inputs, etc.
* update source-maps test due to preflight change
* update changelog
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
* Fix issues with some pseudo-elements
We’ve included pseudo elements for backdrop, marker, placeholder, and selection and they were all “jumpable” before we made changes in v3.3.2. Ideally they wouldn’t be because if they ever eventually have any interactivity that could become a problem.
* Update changelog
* bump `postcss-load-config` in the oxide engine
* bump `postcss-load-config` in the stable engine
* update changelog
* Switch to stable
* Update Node to v14
* Update to latest dependency versions
* Update test helper for new version of `rimraf`
Co-Authored-By: Jordan Pittman <jordan@cryptica.me>
* Downgrade `lightningcss` to `v1.18.0`
Co-Authored-By: Jordan Pittman <jordan@cryptica.me>
* Switch back to oxide
* Update Github actions from Node 12 to Node 14
* Update oxide dependencies
* Update stable dependencies
* Update `content-resolution` integration test dependencies
* Update `postcss-cli` integration test dependencies
* Update `rollup` integration test dependencies
* Update `rollup-sass` integration test dependencies
* Update `vite` integration test dependencies
* Update `webpack-5` integration test dependencies
* Update changelog
* Remove `color-name` dependency
* Replace `quick-lru` dependency with `@alloc/quick-lru`
* Replace `quick-lru` dependency with `@alloc/quick-lru` in stable
* Fix standalone CLI test
---------
Co-authored-by: Jonathan Reinink <jonathan@reinink.ca>
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* ensure we normalize the arbitrary modifiers
This applies the same rules as arbitrary values. The `_` can be used in
place of a space. If you _do_ want an underscore, you can escape it with
`\_` (`\\_` in JavaScript).
* update changelog
* ensure that last `]` doesn't stop the match
Given this input:
```html
<div class="[width:_calc(theme(spacing[5])_+_theme(spacing[5]))]"></div>
```
Then we would expect the match to be this:
```
[width:_calc(theme(spacing[5])_+_theme(spacing[5]))]
```
However, with the `?`, then it would stop and result in:
```
[width:_calc(theme(spacing[5])_+_theme(spacing[5]
```
Which makes it incomplete because the `))]` are missing at the end.
* update changelog
* replace `env.OXIDE` with global `__OXIDE__`
This will allow us to replace the `__OXIDE__` at build time, and fully
remove the branches from the final code so that there is not even any
reference to `@tailwindcss/oxide` on the stable engine.
* update changelog
* use `env.ENGINE` in integration tests
* drop oxide branching for the PostCSS plugin for now
This is currently a redirect to the same file, so doesn't hurt.
* Enable better dead-code elimination
* Update CLI tests
Fix indentation
* Fix indentation
---------
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* 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>
* WIP
* Move warning to validateConfig
This only happens in setupTrackingContext outside of resolveConfig
* Use original dynamic require approach in `validateConfig`
The important thing is that this happens in Node-land only. It is outside of `resolveConfig` which is public and importable into user projects. That is the scenario that breaks because of static import hoisting.
* Don’t reference process when it might be undefined
The `resolveConfig` dep path is public which should not reference process. However, we have some behavior that changes based on env vars so we need to conditionalize it instead.
* Update changelog
* Formatting
* More formatting
* Update changelog
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
Co-authored-by: Jonathan Reinink <jonathan@reinink.ca>
* drop `@tailwindcss/line-clamp` check
This won't work in places where `require` calls are hoisted so that
they become static imports. This means that in some projects this
`require` call was breaking the full application even though it was
intentionally put in a try/catch block...
* update changelog
* 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>
* try to use `config.default` before using `config`
* update changelog
* add quick `SHOW_OUTPUT` toggle for integration tests
Setting this to `true` shows the output of the executed commands.
* add integration tests for `tailwind.config.ts` and `tailwind.config.js` with ESM syntax
* add gradient color stop positions
* update tests to include gradient position color stop reset values
* add dedicated color stop position tests
* use `%` sign in the name of the uility
* update changelog
* ensure `length` values and css variables work
