When the arrays of colors were split, both smaller, and had different values to lookup an `includes` check was faster. Since they’ve been merged a Set is now beneficial.
* move `oxide/crates` to `crates`
* ignore `target/` folder
* ensure pnpm points to `crates` instead of `oxide/crates`
* ensure all paths point to `crates` instead of `oxide/crates`
* update `oxide/crates` -> `crates` path in workflows
* use correct path in .prettierignore
* rename `crates/core` to `crates/oxide`
* remove oxide folder
* fix test script to run `cargo test` directly
Transform Tailwind-generated CSS with Vite CSS plugins. vite:css does useful things like transforming url() paths and inlining images. vite:css-post generates bundle hashes. Before this change, the CSS bundle hash wasn't changing when the generated CSS changed.
Also adds Vite 5.2 peerDependancy.
---------
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* fix incorrect syntax for `translate-z`
This used to be `<length-percentage>`, but we dropped percentage support
because it's not valid in #13321 and I forgot about this one.
* update changelog
* Reorganize to co-locate rotate/skew/transform
* Make 3D rotations composable
* Uppercase axis in rotate functions
* Update changelog
---------
Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
* Use variables with fallbacks for utility classes
* Update playwright test
* rename `resolveBare` to `resolveValue`
* make private methods really private
---------
Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
* fix `transform-gpu` translate syntax
* move `skewX` and `skewY` functions into the variable
* use `transform-[…]` with arbitrary values as-is
This will not have any fallbacks to the `skewX` or `skewY` functions.
The arbitrary values will be the only value that's used.
* use `--tw-skew-{x,y}` variables in `transform-cpu` and `transform-gpu`
* update tests
* drop `skewX` and `skewY` functions because they are embedded in the `--tw-skew-x` and `--tw-skew-y` CSS variables
* drop `transform-cpu` and `transform-gpu`
* add `translate-none`, `transform-none`, `rotate-none` and `scale-none`
* ensure `transform` creates a stacking context
* use `<transform-function>` instead of `<angle>`
* re-add `transform-gpu`
* drop the `,`, because `--tw-skew-x` and `--tw-skew-y` will always be defined by the `@property`
* `translate(0)` is not necessary because `--tw-skew-{x,y}` will always be defined
* add skew variables to `transform-gpu`
Otherwise skew's will be gone
* re-add `transform-cpu`
* make `themeKeys` optional and default to `[]`
* remove `themeKeys` that already map 1:1 to a number or percentage
These can be handled by bare values without issues.
* remove fallback theme key lookup
- In case of `columns`, bare values can be used for the amount of columns
- In case of `divide-width`, we can always look at `--border-width`
* drop theme keys from suggestions
* drop bare value support for `translate-{axis}`
* add todo
* Revert "remove `themeKeys` that already map 1:1 to a number or percentage"
This reverts commit ef3b47aaee.
* Revert "remove fallback theme key lookup"
This reverts commit 0a5fc2dd39.
* Revert "drop theme keys from suggestions"
This reverts commit 7179a19517.
* Revert "add todo"
This reverts commit 7340cdfcf8.
* Remove bare value handling for perspective utilities
* move `perspective-123` example
This is now moved to the spot where we ensure that nothing is generated
at all. This prevents us from accidentally updating a snapshot and
missing a potential bug.
* update changelog
---------
Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
* 3D rotation utilities
* Validate rotate values
* Replace forEach with for loop
* transform-style, transform-box, and backface-visibility utilities
* Tests for transform utilities
* 'perspective' utility
* Fix tests
* Remove unnecessary suggestion; move function comments
* scale-z
* Fix Intellisense test
* perspective-origin
* scale-3d
* Only include the z component of scale if it's defined
We want to avoid triggerring unnecessary 3D transformations.
* Comment the reason for setting --tw-rotate
* Test full bare rotate
* Fix merge
* Comment on rotate arbitrary value
* perspective bare values
Support `perspective-123` (but not `perspective-potato`)
* scale-3d as a static modifier to scale
Instead of scale-3d taking a separate scale, it modifies scale to apply in three dimensions.
* Test that scale-x overrides scale
* scale arbitrary values
Support arbitrary value for scale (e.g. `scale-[1_2_3.5]`).
* Specify rotation axis using a modifier
Support single rotation angles in line with the [CSS `rotate` property](https://developer.mozilla.org/en-US/docs/Web/CSS/rotate). Using modifiers (e.g. `rotate-45/x`) makes it clearer that the axis of rotation is modified. Thanks @adamwathan for this suggestion.
Composing angles is only supported in CSS via a pipeline of `transform` functions. I'll add arbitrary value support to `transform` next as an escape hatch for those cases that need more complex transformations.
* Use property defaults for scale-3d
* `transform` arbitrary values
Support arbitrary values for `transform`. The `skew-x` and `skew-y` transforms are applied before any arbitrary transformations.
* Add translate-z and translate-3d
Both work the same way as scale-z and scale-3d.
* Add translate-[xyz]-px
* Comment on how skewX and skewY are applied
* Remove unnecessary suggest
* Simplify translate
* Fix up comment on rotate syntax
* Back to rotate-x and rotate-y rather than rotate modifiers
* 3D transform test fixes
* handle `.svelte` file
In svelte there is a convention where you can use `<div
class:px-4="condition" />` which means that we extract `class:px-4` as a
utility where `class` is a variant.
This is obviously incorrect, to solve this we can ignore the `class:`
part before parsing the whole file.
This is also what we do in v3.
Ideally we have completely separate parsers for various programming
languages (based on file type) and fallback to the generic one we have
now.
Implementing that, is a much bigger scope.
* flatten match arms
* add test to verify we can parse `class:px-4="condition"`
* explicitly ingore everything but the svelte file
* merge tests
There is some funky stuff happening when running `cargo test` where it
sees contents from another test. Maybe a bug in the tmpdir crate.
I don't see this problem locally when running `cargo nextest run`, but
when using the native `cargo test` command it fails.
* update changelog
* run prettier
* Update oxide/crates/core/src/lib.rs
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* fixup syntax errors
---------
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* add validation for bare values
* add bare value validation to `row-span`, `row-start`, `row-end`, `row-span`, `row-start`, and `row-end`
* update changelog
* validate bare values in `utilities.functional` utilities
* mark candidates as invalid if the leftover value is an empty string
* Update packages/tailwindcss/src/candidate.ts
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* validate `from`, `via` and `to`
This way we make sure that the bare value ends with `%`, and the value
before it is a number.
---------
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* add `pre-publish-optimizations` script
* handle `@import` ourselves
This implementation is fairly simple right now, because we don't have
to worry about resolving folders or modules since we don't use them.
* pretty print index.css file
* update changelog
* Revert "handle `@import` ourselves"
This reverts commit 13a46404c1.
* drop the `1.`
* Update scripts/pre-publish-optimizations.mjs
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* Update CHANGELOG.md
Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
* run prettier
---------
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
* add `@tailwindcss/optimize` as a separate package
* remove lightningcss from `tailwindcss`
* import `optimizeCss` from `@tailwindcss/optimize`
* ensure we use `src/` files in development
* move `devDependencies` after `dependencies`
Just for consistency
* inline `optimizeCss` in leaf packages
Instead of introducing a custom `@tailwindcss/optimize` package
* update changelog
* fix changelog
* Don't rely on existence of --default-transition-* variables in transition utilities
* Update changelog
* Add test with no default transition values defined
* Inline value for --default-transition-timing-function
This is more consistent with how things worked in v3 and ensures things will still work if the user suppresses the output of all CSS variables.
---------
Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
* Support `@theme reference` without `@import`
* Fix test
* Update tests
* Update changelog
---------
Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
* ensure we don't crash on deleted files
* change return type of `compile` to include a `rebuild()` function
This will allow us in the future to perform incremental rebuilds after
the initial rebuild. This is purely the API change so that we can
prepare all the call sites to use this new API.
* set `@tailwind utilities` nodes
Instead of replacing the node that represents the `@tailwind utilities`
with the generated AST nodes from the rawCandidates, we will set the
nodes of the `@tailwind utilities` rule to the AST nodes instead.
This way we dont' have to remove and replace the `@tailwind utilities`
rule with `n` new nodes. This will later allow us to track the
`@tailwindcss utilities` rule itself and update its `nodes` for
incremental rebuilds.
This also requires a small change to the printer where we now need to
print the children of the `@tailwind utilities` rule. Note: we keep the
same `depth` as-if the `@tailwindcss utilities` rule was not there.
Otherwise additional indentation would be present.
* move sorting to the `ast.sort()` call
This will allow us to keep sorting AST nodes in a single spot.
* move parser functions to the `DesignSystem`
This allows us to put all the parsers in the `DesignSystem`, this allows
us to scope the parsers to the current design system (the current theme,
current utility values and variants).
The implementation of these parsers are also using a `DefaultMap`
implementation. This allows us to make use of caching and only parse a
candidate, parse a variant or compile AST nodes for a given raw
candidate once if we've already done this work in the past.
Again, this is scoped to the `DesignSystem` itself. This means that if
the corresponding theme changes, then we will create a new
`DesignSystem` entirely and the caches will be garbage collected. This
is important because a candidate like `bg-primary` can be invalid in
`DesignSystem` A, but can be valid in `DesignSystem` B and vice versa.
* ensure we sort variants alphabetically by root
For incremental rebuilds we don't know all the used variants upfront,
which means that we can't sort them upfront either (what we used to do).
This code now allows us to sort the variants deterministically when
sorting the variants themselves instead of relying on the fact that they
used to be sorted before.
The sort itself could change slightly compared to the previous
implementation (especially when you used stacked variants in your
candidates), but it will still be deterministic.
* replace `localeCompare` comparisons
Use cheaper comparisons than `localeCompare` when comparing 2 strings.
We currently don't care if it is 100% correctly sorted, but we just want
consistent sorting. This is currently faster compared to
`localeCompare`.
Another benefit is that `localeCompare` could result in
non-deterministic results if the CSS was generated on 2 separate
computers where the `locale` is different.
We could solve that by adding a dedicated locale, but it would still be
slower compared to this.
* track invalid candidates
When an incoming raw candidates doesn't produce any output, then we can
mark it as an invalid candidate. This will allow us to reduce the amount
of candidates to handle in incremental rebuilds.
* add initial incremental rebuild implementation
This includes a number of steps:
1. Track the `@tailwind utilities` rule, so that we can adjust its nodes
later without re-parsing the full incoming CSS.
2. Add the new incoming raw candidates to the existing set of
candidates.
3. Parse the merged set to `compileCandidates` (this can accept any
`Iterable<string>`, which means `string[]`, `Set<string>`, ...)
4. Get the new AST nodes, update the `@tailwind utilities` rule's nodes
and re-print the AST to CSS.
* improvement 1: ignore known invalid candidates
This will reduce the amount of candidates to handle. They would
eventually be skipped anyway, but now we don't even have to re-parse
(and hit a cache) at all.
* improvement 2: skip work, when generated AST is the same
Currently incremental rebuilds are additive, which means that we are not
keeping track if we should remove CSS again in development.
We can exploit this information, because now we can quickly check the
amoutn of generated AST nodes.
- If they are the same then nothing new is generated — this means that
we can re-use the previous compiled CSS. We don't even have to
re-print the AST because we already did do that work in the past.
- If there are more AST nodes, something new is generated — this means
that we should update the `@tailwind utilities` rule and re-print the
CSS. We can store the result for future incremental rebuilds.
* improvement 3: skip work if no new candidates are detected
- We already know a set of candidates from previous runs.
- We also already know a set of candidates that are invalid and don't
produce anything.
This means that an incremental rebuild could give us a new set of
candidates that either already exist or are invalid.
If nothing changes, then we can re-use the compiled CSS.
This actually happens more often than you think, and the bigger your
project is the better this optimization will be.
For example:
```
// Imagine file A exists:
<div class="flex items-center justify-center"></div>
<button class="text-red-500">Delete</button>
```
```
// Now you add a second file B:
<div class="text-red-500 flex"></div>
```
You just created a brand new file with a bunch of HTML elements and
classes, yet all of the candidates in file B already exist in file A, so
nothing changes to the actual generated CSS.
Now imagine the other hundreds of files that already contain hundreds of
classes.
The beauty of this optimization is two-fold:
- On small projects, compiling is very fast even without this check.
This means it is performant.
- On bigger projects, we will be able to re-use existing candidates.
This means it stays performant.
* remove `getAstNodeSize`
We can move this up the tree and move it to the `rebuild` function
instead.
* remove invalid candidate tracking from `DesignSystem`
This isn't used anywhere but only in the `rebuild` of the compile step.
This allows us to remove it entirely from core logic, and move it up the
chain where it is needed.
* replace `throwOnInvalidCandidate` with `onInvalidCanidate`
This was only needed for working with `@apply`, now this logic _only_
exists in the code path where we are handling `@apply`.
* update `compile` API signature
* update callsite of `compile()` function
* fix typo
* Reset borders, padding, and margin universally
Noticed iframes have a default border we weren't resetting, feels safest to just remove borders across the board and reintroduce them for form controls.
We were also resetting padding on an element by element basis but I can't think of any elements we are actually trying to avoid resetting padding on, so just reset it everywhere.
This also removes the left margin on file buttons that separates the button from the meta data about the currently selected file but I think this is fine, let the user decide how much space to put there intentionally like we do with other things.
* Include ::first-letter
Supports margin/padding/border (but not box-sizing) so should be in reset list.
* Update changelog
---------
Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
* Vite plugin: stop checking CSS files that no longer exist
Fix a potential memory leak in the Vite plugin. If CSS files are created that include `@tailwind` and later deleted, remove them from the list of files checked.
Thanks to @timneutkens for highlighting this issue.
* Vite plugin: don't log when files are removed
