* 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
* add `listStyle` instead of `listStyleType`
Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* add `listStyleType` related deprecation warnings
* Implement list-style-image as separate plugin
* Remove unused code, update tests
* Always generate `list-none`, don't pull it from theme
* Gracefully handle missing listStyleType configuration
* Just use `list-image-*` fuck it
* Update changelog
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
Co-authored-by: Peter Neupauer <peter@neupauer.sk>
* 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!
* bump lightningcss
* use `lightningcss` in the main PostCss Plugin
* use lightningcss in our custom matchers
Now that we are using `lightningcss` and nesting in the new `oxide`
engine, the generated output _will_ be different in the majority of test
cases.
Using a combination of `prettier` and `lightningcss` will make the
output consistent.
The moment we are fully using the `oxide` engine, we can drop
`lightningcss` or `prettier` again to improve the performance of the
tests.
* update tests to apply `lightningcss` related changes
* update changelog
* add `lightningcss` and `browserslist` as dev dependencies to stable package.json
* only use `lightningcss` in tests (without prettier)
We will only fallback to prettier if lightningcss fails somehow.
* apply side effect chagnes due to only using lightningcss for tests
* make CI happy (integration tests)
Apply changes to integration tests now that we are using lightningcss
* transform `lightningcss` for Node 12 when running tests
* run prettier on failing tests for `toMatchFormattedCss`
This will result in better diffs because diffs are typically per block
and/or per line. But lightningcss will simplify certain selectors and
the diff won't be as clear.
We will only apply the prettier formatting for failing tests in the diff
view so that diffs are cleaner and we don't pay for the additional
prettier calls when tests pass.
* temporarily disable workflows
* add oxide
Our Rust related parts
* use oxide
- Setup the codebase to be able to use the Rust parts based on an
environment variable: `OXIDE=1`.
- Setup some tests that run both the non-Rust and Rust version in the
same test.
- Sort the candidates in a consistent way, to guarantee the order for
now (especially in tests).
- Reflect sorting related changes in tests.
- Ensure tests run in both the Rust and non-Rust version. (Some tests
are explicitly skipped when using the Rust version since we haven't
implemented those features yet. These include: custom prefix,
transformers and extractors).
- `jest`
-`OXIDE=1 jest`
* remove into_par_iter where it doesn't make sense
* cargo fmt
* wip
* enable tracing based on `DEBUG` env
* improve CI for the Oxide build
* sort test output
This happened because the sorting happens in this branch, but changes
happened on the `master` branch.
* add failing tests
I noticed that some of the tests were failing, and while looking at
them, it happened because the tests were structured like this:
```html
<div
class="
backdrop-filter
backdrop-filter-none
backdrop-blur-lg
backdrop-brightness-50
backdrop-contrast-0
backdrop-grayscale
backdrop-hue-rotate-90
backdrop-invert
backdrop-opacity-75
backdrop-saturate-150
backdrop-sepia
"
></div>
```
This means that the class names themselves eventually end up like this: `backdrop-filter-none\n`
-> (Notice the `\n`)
/cc @thecrypticace
* fix range to include `\n`
* Include only unique values for tests
Really, what we care about most is that the list contains every expected candidate. Not necessarily how many times it shows up because while many candidates will show up A LOT in a source text we’ll unique them before passing them back to anything that needs them
* Fix failing tests
* Don’t match empty arbitrary values
* skip tests in oxide mode regarding custom separators in arbitrary variants
* re-enable workflows
* use `@tailwindcss/oxide` dependency
* publish `tailwindcss@oxide`
* drop prepublishOnly
I don't think we actually need this anymore (or even want because this
is trying to do things in CI that we don't want to happen. Aka, build
the Oxide Rust code, it is already a dependency).
* WIP
* Defer to existing CLI for Oxide
* Include new compiled typescript stuff when publishing
* Move TS to ./src/oxide
* Update scripts
* Clean up tests for TS
* copy `cli` to `oxide/cli`
* make CLI files TypeScript files
* drop --postcss flag
* setup lightningcss
* Remove autoprefixer and cssnano from oxide CLI
* cleanup Rust code a little bit
- Drop commented out code
- Drop 500 fixture templates
* sort test output
* re-add `prepublishOnly` script
* bump SWC dependencies in package-lock.json
* pin `@swc` dependencies
* ensure to install and build oxide
* update all GitHub Workflows to reflect Oxide required changes
* sort `content-resolution` integration tests
* add `Release Insiders — Oxide`
* setup turbo repo + remote caching
* use `npx` to invoke `turbo`
* setup unique/proper package names for integration tests
* add missing `isomorphic-fetch` dependency
* setup integration tests to use `turborepo`
* scope tailwind tasks to root workspace
* re-enable `node_modules` cache for integration tests
* re-enable `node_modules` cache for main CI workflow
* split cache for `main` and `oxide` node_modules
* fix indent
* split install dependencies so that they can be cached individually
* improve GitHub actions caching
* use correct path for oxide node_modules (crates/node)
* ensure that `cargo install` always succeeds
cargo install X, on CI will fail if it already exists.
* figure out integration tests with turbo
* tmp: use `npm` instead of `turbo`
* disable `fail-fast`
This will allow us to run integration tests so that it still caches the
succesful ones.
* YAML OH YAML, Y U WHITESPACE SENSITIVE
* copy the oxide-ci workflow to release-oxide
* make `oxide-ci` a normal CI workflow
Without publishing
* try to cache cargo and node_modules for the oxide build
* configure turbo to run scripts in the root
* explicitly skip failing test for the Oxide version
* run oxide tests in CI
* only use build script for root package
* sync package-lock.json
* do not cache node_modules for each individual integration
* look for hoisted `.bin`
* use turbo for caching build tailwind css in integration tests
* Robin...
* try to use the local binary first
* skip installing integration test dependencies
Should already be installed due to workspace usage
* Robin...
* drop `output.clean`
* explicitly add `mini-css-extract-plugin`
* drop oxide-ci, this is tested by proxy
* ensure oxide build is used in integration tests
This will ensure the `@tailwindcss/oxide` dependency is available
(whether we use it or not).
* setup Oxide shim in insiders release
* add browserslist dependency
* use `install:all` script name
Just using `install` as a script name will be called when running
`npm install`.
Now that we marked the repo as a `workspace`, `npm install` will run
install in all workspaces which is... not ideal.
* tmp: enable insiders release in PRs
Just to check if everything works before merging. Can be removed once
tested.
* don't cache node_modules?
I feel there is some catch 22 going on here.
We require `npm install` to build the `oxide/crates/node` version.
But we also require `oxide/crates/node` for the `npm install` becaus of
the dependency: `"@tailwindcss/oxide": "file:oxide/creates/node"`
* try to use `oxide/crates/node` as part of the workspace
* let's think about this
Let's try and cache the `node_modules` and share as much as possible.
However, some scripts still need to be installed specific to the OS.
Running `npm install` locally doesn't throw away your `node_modules`,
so if we just cache `node_modules` but also run `npm install` that
should keep as much as possible and still improve install times since
`node_modules` is already there.
I think.
* ensure generated `index.js` and `index.d.ts` files are considered outputs
* use `npx napi` instead of `napi` directly
* include all `package-lock.json` files
* normalize caching further in all workflows
* drop nested `package-lock.json` files
* `npm uninstall mini-css-extract-plugin && npm install mini-css-extract-plugin --save-dev`
* bump webpack-5 integration tests dependencies
* only release insiders on `master` branch
* tmp: let's figure out release insiders oxide
* fix little typo
* use Node 18 for Oxide Insiders
* syncup package-lock.json
* let's try node 16
Node 18 currently fails on `Build x86_64-unknown-linux-gnu (OXIDE)`
Workflow.
Install Node.JS output:
```
Environment details
Warning: /__t/node/18.13.0/x64/bin/node: /lib64/libm.so.6: version `GLIBC_2.27' not found (required by /__t/node/18.13.0/x64/bin/node)
/__t/node/18.13.0/x64/bin/node: /lib64/libc.so.6: version `GLIBC_2.25' not found (required by /__t/node/18.13.0/x64/bin/node)
/__t/node/18.13.0/x64/bin/node: /lib64/libc.so.6: version `GLIBC_2.28' not found (required by /__t/node/18.13.0/x64/bin/node)
/__t/node/18.13.0/x64/bin/node: /lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by /__t/node/18.13.0/x64/bin/node)
/__t/node/18.13.0/x64/bin/node: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /__t/node/18.13.0/x64/bin/node)
/__t/node/18.13.0/x64/bin/node: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /__t/node/18.13.0/x64/bin/node)
Warning: node: /lib64/libm.so.6: version `GLIBC_2.27' not found (required by node)
node: /lib64/libc.so.6: version `GLIBC_2.25' not found (required by node)
node: /lib64/libc.so.6: version `GLIBC_2.28' not found (required by node)
node: /lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by node)
node: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by node)
node: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by node)
```
* bump some Node versions
* only release oxide insiders on `master` branch
* don't cache `npm`
* bump napi-rs
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
* use test with non-any type plugin
* choose backgroundSize over backgroundPosition
Ensure that `backgroundColor` can take any value
* add tests to verify fallback plugins
* implement fallback plugins
Whenever an arbitrary value results in css from multiple plugins we
first try to resolve a falback plugin.
The fallback mechanism works like this:
- If A has type `any` and B has type `color`, then B should win.
> This is because `A` will match *anything*, but the more precise type
should win instead. E.g.: `backgroundColor` has the type `any` so
`bg-[100px_200px]` would match both the `backgroundColor` and
`backgroundSize` but `backgroundSize` matched because of a specific
type and not because of the `any` type.
- If A has type `length` and B has type `[length, { disambiguate: true }]`, then B should win.
> This is because `B` marked the `length` as the plugin that should
win in case a clash happens.
* Add any type to a handful of plugins
Needs tests tho
* Add any type to `border-{x,y,t,r,b,l}` plugins
* Add test for any type
* Split on multiple lines
* fixup
* add tests for implicit `any` types
* rename `disambiguate` to `preferOnConflict`
* update tests to reflect `any` types a bit better
* update changelog
* annotate any-type test with a bit more information
Just for future debugging reasons!
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* improve split logic by delimiter
The original RegEx did mostly what we want, the idea is that we wanted
to split by a `,` but one that was not within `()`. This is useful when
you define multiple background colors for example:
```html
<div class="bg-[rgb(0,0,0),rgb(255,255,255)]"></div>
```
In this case splitting by the regex would result in the proper result:
```js
let result = [
'rgb(0,0,0)',
'rgb(255,255,255)'
]
```
Visually, you can think of it like:
```
┌─[./example.html]
│
∙ 1 │ <div class="bg-[rgb(0,0,0),rgb(255,255,255)]"></div>
· ──┬── ┬ ─────┬─────
· │ │ ╰─────── Guarded by parens
· │ ╰───────────────── We will split here
· ╰───────────────────── Guarded by parens
│
└─
```
We properly split by `,` not inside a `()`. However, this RegEx fails
the moment you have deeply nested RegEx values.
Visually, this is what's happening:
```
┌─[./example.html]
│
∙ 1 │ <div class="bg-[rgba(0,0,0,var(--alpha))]"></div>
· ┬ ┬ ┬
· ╰─┴─┴── We accidentally split here
│
└─
```
This is because on the right of the `,`, the first paren is an opening
paren `(` instead of a closing one `)`.
I'm not 100% sure how we can improve the RegEx to handle that case as
well, instead I wrote a small `splitBy` function that allows you to
split the string by a character (just like you could do before) but
ignores the ones inside the given exceptions. This keeps track of a
stack to know whether we are within parens or not.
Visually, the fix looks like this:
```
┌─[./example.html]
│
∙ 1 │ <div class="bg-[rgba(0,0,0,var(--alpha)),rgb(255,255,255,var(--alpha))]"></div>
· ┬ ┬ ┬ ┬ ┬ ┬ ┬
· │ │ │ │ ╰───┴───┴── Guarded by parens
· │ │ │ ╰────────────────── We will split here
· ╰─┴─┴──────────────────────────────── Guarded by parens
│
└─
```
* use already existing `splitAtTopLevelOnly` function
* add faster implemetation for `splitAtTopLevelOnly`
However, the faster version can't handle separators with multiple
characters right now. So instead of using buggy code or only using the
"slower" code, we've added a fast path where we use the faster code
wherever we can.
* use `splitAtTopLevelOnly` directly
* make split go brrrrrrr
* update changelog
* remove unncessary array.from call
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* remove `any` data type for decoration color plugin
The main reason for the `any` type is so that we don't have to parse the
value and can assume that this plugin handles "any" value you give it.
This is useful because `decoration-[var(--something)]` would be
correctly translated to the correct decoration property. However, we
introduce another plugin with the same `decoration` prefix.
This means that now both `textDecorationColor` and
`textDecorationThickness` have the same base utility name: `decoration`.
- `textDecorationColor` had ['color', 'any']
- `textDecorationThickness` had ['length', 'percentage']
This means that `3px` fit both in the `length` data type of the
`textDecorationThickness` plugin and in the `any` data type of the
`textDecorationColor` plugin.
Removing the `any` fixes this.
TL;DR: Only have `any` when there are no conflicting utility names.
* remove utility that doesn't generate css
Having `decoration-[var(--abc)]` is ambiguous because there are multiple
plugins that have a `decoration` utility name. In order for this to work
you have to prefix it with the type: `decoration-[color:var(--abc)]`
which is already tested in this file.
* Add new outline style, color, width and offset utilities
Co-Authored-By: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
* Remove old `outline` property from default config
Co-Authored-By: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
* Tweak order of outline plugins
Co-Authored-By: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
* Revert to previous `outline-none` styles
Co-Authored-By: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
* Drop quotes from outline property
* Add offset back to `outline-none` utility
Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
* remove unused `withRule`
* ensure all ::before and ::after elements have content
* update --tw-content for the content plugin
* simplify `before` and `after` variants
* update tests, to reflect changes
* make new `format` and `wrap` API's private for now
* allow returning a format string from `addVariant` callback
* add `content: var(--tw-content)` for before/after variants
* update tests to add `content: var(--tw-content)`
* update changelog
* utilities and tests in place for textDecorationColor and textDecorationOpacity
* change 'backgroundColor' to 'textDecorationColor' in corePlugin declaration for latter
* remove explicit textDecorationOpacity utility (the JIT slash syntax suffices)
Co-authored-by: Michael Warner <michaelwarner@Michaels-MacBook-Pro.local>
This adds `grow-*` and `shrink-*` utilities as aliases for `flex-grow-*` and `flex-shrink-*` since those names are unnecessarily verbose. We will stop documenting the long form ones and consider them deprecated.
```diff
- <div class="flex-grow-0 flex-shrink">
+ <div class="grow-0 shrink">
```
* simplify `inset` plugin
* run `prettier` on stub file
* simplify `align` utility
* improve arbitrary support for outline
This will allow us to use `outline-[OUTLINE,OPTIONAL_OFFSET]`
Input:
```html
outline-[2px_solid_black]
```
Output:
```css
.outline-\[2px_solid_black\] {
outline: 2px solid black;
outline-offset: 0;
}
```
---
Input:
```html
outline-[2px_solid_black,2px]
```
Output:
```css
.outline-\[2px_solid_black\2c 2px\] {
outline: 2px solid black;
outline-offset: 2px;
}
```
* remove default `type`
* simplify createUtilityPlugin, use types directly
* find first matching type when coercing the value
* introduce css data types
Ref: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Types
These data types will be used to "guess" the type of an arbitrary value
if there is some ambiguity going on. For example:
```
bg-[#0088cc] -> This is a `color` -> `background-color`
bg-[url('...')] -> This is a `url` -> `background-image`
```
If you are using css variables, then there is no way of knowing which
type it is referring to, in that case you can be explicit:
```
bg-[color:var(--value)] -> This is a `color` -> `background-color`
bg-[url:var(--value)] -> This is a `url` -> `background-image`
```
When you explicitly pass a data type, then we bypass the type system and
assume you are right. This is nice in a way because now we don't have to
run all of the guessing type code. On the other hand, you can introduce
runtime issues that we are not able to detect:
```
:root {
--value: 12px;
}
/* Later... */
bg-[color:var(--value)] -> Assumes `color` -> *eventually* -> `background-color: 12px`
```
* add a bunch of new tests for advanced arbitrary values
* add url to resolveArbitraryValue list
* add `asURL` data type
* add `bg-[url('..')]` regex
* allow for `resolveArbitraryValue` to be an array
* prevent spaces around `-` when in a `url`
* add tests to verify `bg-[url('...')]` and `stroke-[url(...)]`
* move to real regexes
These regexes are only calculated once so we don't really have a
performance penalty here. However, it's a bit nicer to do it this way
because now you don't have to think about the proper escapes.
/.*/.source will basically take the source of the regex ".*" without
flags and converts it to a string with the proper escapes for you.
Fun fact, this `.source` property has been supported since Chrome,
Firefox and Safari version 1.
* allow for `'>'` in `content-['>']`
* 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>
* move `./tests/jit` to `./tests`
* make tests consistent
Abstracted a `run` function and some syntax highlighting helpers for
`html`, `css` and `javascript`.
