Upgrading `lightningcss` to fix invalid `list-style: none` conversion.
I've also reverted the change to preflight while at it, since it's no
longer necessary.
This PR adds a `main` and `browser` field for the `@tailwindcss/browser`
package.
In the package, we do have the `exports` field setup, which is an
alternative to the `main` field according to the docs:
> The "exports" provides a modern alternative to "main" …
>
> —
https://docs.npmjs.com/cli/v10/configuring-npm/package-json?v=true#exports
However, if you look at the unpkg link:
https://unpkg.com/@tailwindcss/browser, it tries to load the `index.js`
file. This is probably a bug in the unpkg resolver.
That said, if you look at other CDNs such as esm.sh, it does resolve
correctly: https://esm.sh/@tailwindcss/browser
According to the npm docs:
> If `main` is not set, it defaults to `index.js` in the package's root
folder.
>
> —
https://docs.npmjs.com/cli/v10/configuring-npm/package-json?v=true#main
This explains why unpkg is trying to load the `index.js` file.
Additionally, the npm docs also mention the `browser` field:
> If your module is meant to be used client-side the browser field
should be used instead of the main field. This is helpful to hint users
that it might rely on primitives that aren't available in Node.js
modules. (e.g. window)
>
> —
https://docs.npmjs.com/cli/v10/configuring-npm/package-json?v=true#browser
So this PR also adds that field just to be sure.
Here is everything you need to know about this update. Please take a
good look at what changed and the test results before merging this pull
request.
### What changed?
#### ✳️ prettier (3.3.3 → 3.4.2) ·
[Repo](https://github.com/prettier/prettier) ·
[Changelog](https://github.com/prettier/prettier/blob/main/CHANGELOG.md)
<details>
<summary>Release Notes</summary>
<h4><a
href="https://github.com/prettier/prettier/releases/tag/3.4.2">3.4.2</a></h4>
<blockquote><p dir="auto">🔗 <a
href="https://bounce.depfu.com/github.com/prettier/prettier/blob/main/CHANGELOG.md#342">Changelog</a></p></blockquote>
<h4><a
href="https://github.com/prettier/prettier/releases/tag/3.4.1">3.4.1</a></h4>
<blockquote><p dir="auto">🔗 <a
href="https://bounce.depfu.com/github.com/prettier/prettier/blob/main/CHANGELOG.md#341">Changelog</a></p></blockquote>
<p><em>Does any of this look wrong? <a
href="https://depfu.com/packages/npm/prettier/feedback">Please let us
know.</a></em></p>
</details>
<details>
<summary>Commits</summary>
<p><a
href="52829385bc...cca946176c">See
the full diff on Github</a>. The new version differs by more commits
than we can show here.</p>
</details>
---
[Depfu](https://depfu.com) will automatically keep this PR
conflict-free, as long as you don't add any commits to this branch
yourself. You can also trigger a rebase manually by commenting with
`@depfu rebase`.
<details><summary>All Depfu comment commands</summary>
<blockquote><dl>
<dt>@depfu rebase</dt><dd>Rebases against your default branch and
redoes this update</dd>
<dt>@depfu recreate</dt><dd>Recreates this PR, overwriting any edits
that you've made to it</dd>
<dt>@depfu merge</dt><dd>Merges this PR once your tests are passing and
conflicts are resolved</dd>
<dt>@depfu cancel merge</dt><dd>Cancels automatic merging of this
PR</dd>
<dt>@depfu close</dt><dd>Closes this PR and deletes the branch</dd>
<dt>@depfu reopen</dt><dd>Restores the branch and reopens this PR (if
it's closed)</dd>
<dt>@depfu pause</dt><dd>Ignores all future updates for this dependency
and closes this PR</dd>
<dt>@depfu pause [minor|major]</dt><dd>Ignores all future minor/major
updates for this dependency and closes this PR</dd>
<dt>@depfu resume</dt><dd>Future versions of this dependency will
create PRs again (leaves this PR as is)</dd>
</dl></blockquote>
</details>
Co-authored-by: depfu[bot] <23717796+depfu[bot]@users.noreply.github.com>
Here is everything you need to know about this update. Please take a
good look at what changed and the test results before merging this pull
request.
### What changed?
#### ✳️ enhanced-resolve (5.17.1 → 5.18.0) ·
[Repo](https://github.com/webpack/enhanced-resolve)
<details>
<summary>Release Notes</summary>
<h4><a
href="https://github.com/webpack/enhanced-resolve/releases/tag/v5.18.0">5.18.0</a></h4>
<blockquote><h3 dir="auto">Features</h3>
<ul dir="auto">
<li>Added wildcards support for aliases</li>
</ul></blockquote>
<p><em>Does any of this look wrong? <a
href="https://depfu.com/packages/npm/enhanced-resolve/feedback">Please
let us know.</a></em></p>
</details>
<details>
<summary>Commits</summary>
<p><a
href="247edebc90...27e457a905">See
the full diff on Github</a>. The new version differs by 9 commits:</p>
<ul>
<li><a
href="27e457a905"><code>chore(release):
5.18.0</code></a></li>
<li><a
href="88ceebe3cc"><code>feat:
add wildcards support for aliases</code></a></li>
<li><a
href="35b67ce834"><code>feat:
add wildcards</code></a></li>
<li><a
href="4fbcfa1c83"><code>chore(deps):
bump cross-spawn from 7.0.3 to 7.0.6</code></a></li>
<li><a
href="572a54f0c6"><code>chore(deps):
bump cross-spawn from 7.0.3 to 7.0.6</code></a></li>
<li><a
href="af4e2fb155"><code>ci:
add Node.js v23</code></a></li>
<li><a
href="bf443c04ac"><code>ci:
add Node.js v23</code></a></li>
<li><a
href="72999caf00"><code>chore(deps):
bump micromatch from 4.0.5 to 4.0.8</code></a></li>
<li><a
href="fbee162cc2"><code>chore(deps):
bump micromatch from 4.0.5 to 4.0.8</code></a></li>
</ul>
</details>
---
[Depfu](https://depfu.com) will automatically keep this PR
conflict-free, as long as you don't add any commits to this branch
yourself. You can also trigger a rebase manually by commenting with
`@depfu rebase`.
<details><summary>All Depfu comment commands</summary>
<blockquote><dl>
<dt>@depfu rebase</dt><dd>Rebases against your default branch and
redoes this update</dd>
<dt>@depfu recreate</dt><dd>Recreates this PR, overwriting any edits
that you've made to it</dd>
<dt>@depfu merge</dt><dd>Merges this PR once your tests are passing and
conflicts are resolved</dd>
<dt>@depfu cancel merge</dt><dd>Cancels automatic merging of this
PR</dd>
<dt>@depfu close</dt><dd>Closes this PR and deletes the branch</dd>
<dt>@depfu reopen</dt><dd>Restores the branch and reopens this PR (if
it's closed)</dd>
<dt>@depfu pause</dt><dd>Ignores all future updates for this dependency
and closes this PR</dd>
<dt>@depfu pause [minor|major]</dt><dd>Ignores all future minor/major
updates for this dependency and closes this PR</dd>
<dt>@depfu resume</dt><dd>Future versions of this dependency will
create PRs again (leaves this PR as is)</dd>
</dl></blockquote>
</details>
Co-authored-by: depfu[bot] <23717796+depfu[bot]@users.noreply.github.com>
This PR makes sure that the `--theme(…)` CSS function can only be used
with the modern syntax. For backwards compatibility, the `theme(…)`
function must be used with the older dot notation.
This PR improves the codemod tool to simplify 2 things:
1. Whenever you have a `theme(…)` call, we try to change it to a
`var(…)`, but if that doesn't work for some reason, we will make sure to
at least convert it to the more modern `--theme(…)`.
2. When converting `theme(spacing.2)`, we used to convert it to
`calc(var(--spacing)*2)`, but now we will convert it to `--spacing(2)`
instead.
Closes#15438Closes#15560Closes#15561Closes#15562
This PR upgrades `lightningcss` to `1.29.0` and uses the [new feature
flag](304389600f)
to disable the light-dark function transpilation.
This PR fixes an issue where JavaScript plugins were still able to
contribute `@keyframes` when loaded inside an `@reference` import. This
was possible because we only gated the `addBase` API and not the
`addUtilities` one which also has a special branch to handle `@keyframe`
rules.
To make this work, we have to create a new instance of the plugin API
that has awareness of wether the plugin accessing it is inside reference
import mode.
## Test plan
Added a unit test that reproduces the issue observed via #15544
This PR fixes an issue where static utilities defined via `@utility`
wasn't possible if the name starts with `-`.
There are plenty of static utilities that start with `-`, but it wasn't
possible to register them via the `@utility` directive, only via the JS
API.
Example of a core utility that is now valid:
```css
@utility -inset-full {
inset: -100%;
}
```
This PR implements new CSS functions that you can use in your CSS (or
even in arbitrary value position).
For starters, we renamed the `theme(…)` function to `--theme(…)`. The
legacy `theme(…)` function is still available for backwards
compatibility reasons, but this allows us to be future proof since
`--foo(…)` is the syntax the CSS spec recommends. See:
https://drafts.csswg.org/css-mixins/
In addition, this PR implements a new `--spacing(…)` function, this
allows you to write:
```css
@import "tailwindcss";
@theme {
--spacing: 0.25rem;
}
.foo {
margin: --spacing(4):
}
```
This is syntax sugar over:
```css
@import "tailwindcss";
@theme {
--spacing: 0.25rem;
}
.foo {
margin: calc(var(--spacing) * 4);
}
```
If your `@theme` uses the `inline` keyword, we will also make sure to
inline the value:
```css
@import "tailwindcss";
@theme inline {
--spacing: 0.25rem;
}
.foo {
margin: --spacing(4):
}
```
Boils down to:
```css
@import "tailwindcss";
@theme {
--spacing: 0.25rem;
}
.foo {
margin: calc(0.25rem * 4); /* And will be optimised to just 1rem */
}
```
---
Another new function function we added is the `--alpha(…)` function that
requires a value, and a number / percentage value. This allows you to
apply an alpha value to any color, but with a much shorter syntax:
```css
@import "tailwindcss";
.foo {
color: --alpha(var(--color-red-500), 0.5);
}
```
This is syntax sugar over:
```css
@import "tailwindcss";
.foo {
color: color-mix(in oklab, var(--color-red-500) 50%, transparent);
}
```
---------
Co-authored-by: Philipp Spiess <hello@philippspiess.com>
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
Co-authored-by: Jonathan Reinink <jonathan@reinink.ca>
This PR adds support for functional utilities constructed via CSS.
# Registering functional utilities in CSS
To register a functional utility in CSS, use the `@utility potato-*`
syntax, where the `-*` signals that this is a functional utility:
```css
@utility tab-* {
tab-size: --value(--tab-size-*);
}
```
## Resolving values
The special `--value(…)` function is used to resolve the utility value.
### Resolving against `@theme` values
To resolve the value against a set of theme keys, use
`--value(--theme-key-*)`:
```css
@theme {
--tab-size-1: 1;
--tab-size-2: 2;
--tab-size-4: 4;
--tab-size-github: 8;
}
@utility tab-* {
/* tab-1, tab-2, tab-4, tab-github */
tab-size: --value(--tab-size-*);
}
```
### Bare values
To resolve the value as a bare value, use `--value({type})`, where
`{type}` is the data type you want to validate the bare value as:
```css
@utility tab-* {
/* tab-1, tab-76, tab-971 */
tab-size: --value(integer);
}
```
### Arbitrary values
To support arbitrary values, use `--value([{type}])` (notice the square
brackets) to tell Tailwind which types are supported as an arbitrary
value:
```css
@utility tab-* {
/* tab-[1], tab-[76], tab-[971] */
tab-size: --value([integer]);
}
```
### Supporting theme values, bare values, and arbitrary values together
All three forms of the `--value(…)` function can be used within a rule
as multiple declarations, and any declarations that fail to resolve will
be omitted in the output:
```css
@theme {
--tab-size-github: 8;
}
@utility tab-* {
tab-size: --value([integer]);
tab-size: --value(integer);
tab-size: --value(--tab-size-*);
}
```
This makes it possible to treat the value differently in each case if
necessary, for example translating a bare integer to a percentage:
```css
@utility opacity-* {
opacity: --value([percentage]);
opacity: calc(--value(integer) * 1%);
opacity: --value(--opacity-*);
}
```
The `--value(…)` function can also take multiple arguments and resolve
them left to right if you don't need to treat the return value
differently in different cases:
```css
@theme {
--tab-size-github: 8;
}
@utility tab-* {
tab-size: --value(--tab-size-*, integer, [integer]);
}
@utility opacity-* {
opacity: calc(--value(integer) * 1%);
opacity: --value(--opacity-*, [percentage]);
}
```
### Negative values
To support negative values, register separate positive and negative
utilities into separate declarations:
```css
@utility inset-* {
inset: calc(--var(--spacing) * --value([percentage], [length]));
}
@utility -inset-* {
inset: calc(--var(--spacing) * --value([percentage], [length]) * -1);
}
```
## Modifiers
Modifiers are handled using the `--modifier(…)` function which works
exactly like the `--value(…)` function but operates on a modifier if
present:
```css
@utility text-* {
font-size: --value(--font-size-*, [length]);
line-height: --modifier(--line-height-*, [length], [*]);
}
```
If a modifier isn't present, any declaration depending on a modifier is
just not included in the output.
## Fractions
To handle fractions, we rely on the CSS `ratio` data type. If this is
used with `--value(…)`, it's a signal to Tailwind to treat the value +
modifier as a single value:
```css
/* The CSS `ratio` type is our signal to treat the value + modifier as a fraction */
@utility aspect-* {
/* aspect-square, aspect-3/4, aspect-[7/9] */
aspect-ratio: --value(--aspect-ratio-*, ratio, [ratio]);
}
```
This PR adds a new `@reference "…"` API as an replacement for the
previously added [`@import "…"
reference`](https://github.com/tailwindlabs/tailwindcss/pull/15228). The
motivation for a distinct at rule is that `@import` is already handled
outside of Tailwind in some scenarios (e.g. when using in combination
with postcss-import, other pre-processors, or frameworks like Svelte).
While our implementation of hijacking the `media` attribute _works in
this cases_, it can cause annoying linter issues because tooling build
around `@import` does not know about our behavior.
To fix this, we've decided to move this mode into a separate at rule
that is passed-through in the other tooling. Here's an example of how
this would look like in Svelte:
```svelte
<h1>Hello world!</h1>
<style>
@reference './theme.css';
h1 {
color: var(--theme-color);
}
</style>
```
With this change, the Svelte linter would not be detecting unused CSS
from the `theme.css` file as it would if we'd rely on `@import`.
This PR fixes an issue where using an `@utility` before it is defined,
and _if_ that `@utility` contains `@apply`, that it won't result in the
expected output. But results in an `@apply` rule that is not
substituted. Additionally, if you have multiple levels of `@apply`, we
have to make sure that everything is applied (no pun intended) in the
right order.
Right now, the following steps are taken:
1. Collect all the `@utility` at-rules (and register them in the system
as utilities).
2. Substitute `@apply` on the AST (including `@utility`'s ASTs) with the
content of the utility.
3. Delete the `@utility` at-rules such that they are removed from the
CSS output itself.
The reason we do it in this order is because handling `@apply` during
`@utility`
handling means that we could rely on another `@utility` that is defined
later
and therefore the order of the utilities starts to matter. This is not a
bad
thing, but the moment you import multiple CSS files or plugins, this
could
become hard to manage.
Another important step is that when using `@utility foo`, the
implementation creates a `structuredClone` from its AST when first using
the utility. The reason we do that is because `foo` and `foo!` generate
different output and we don't want to accidentally mutate the same AST.
This structured clone is the start of the problem in the linked issue
(#15501).
If we don't do the structured clone, then substituting the `@apply`
rules would work, but then `foo` and `foo!` will generate the same
output, which is bad.
The linked issue has this structure:
```css
.foo {
@apply bar;
}
@utility bar {
@apply flex;
}
```
If we follow the steps above, this would substitute `@apply bar` first,
which
results in:
```css
.foo {
@apply flex;
}
```
But the `bar` utility, was already cloned (and cached) so now we end up
with an `@apply` rule that is not substituted.
To properly solve this problem, we have to make sure that we collect all
the `@apply` at-rules, and apply them in the correct order. To do this,
we run a topological sort on them which ensures that all the
dependencies are applied before substituting the current `@apply`.
This means that in the above example, in order to process `@apply bar`,
we have to process the `bar` utility first.
If we run into a circular dependency, then we will throw an error like
before. You'll notice that the error message in this PR is updated to a
different spot. This one is a bit easier to grasp because it shows the
error where the circular dependency _starts_ not where it _ends_ (and
completes the circle). The previous message was not wrong (since it's a
circle), but now it's a bit easier to reason about.
Fixes: #15501
This PR prevents the migration of utilities detected in function names,
e.g.: the use of `shadow` inside `filter: 'drop-shadow(…)'`.
## Test plan
Have content like this in a project you're migrating using the upgrade
tool:
```js
{
filter: 'drop-shadow(0 0 0.5rem #000)'
}
```
This was verified by adding unit tests to the specific codemods and
adding an integration test.
This PR is a tiny improvement to the `walk(…)` implementations, not a
super big
deal but thought about something and was pleasently surprised that it
did have
an impact.
The idea is twofold:
1. Reduce array allocations while walking to build a `path` to the
current node. This re-uses the existing `path` array and pushes the
current node before the recursive call and pops it afterwards. This way
we don't need to allocate a new array for each recursive call. Testing
this on Tailwind UI means ~14k fewer allocations.
2. Instead of always calling `.splice(…)`, we can directly update a
single value in the array if we are replacing a node with another node.
Testing on the Tailwind UI codebase, this results in:
---------
Co-authored-by: Philipp Spiess <hello@philippspiess.com>
Here is everything you need to know about this upgrade. Please take a
good look at what changed and the test results before merging this pull
request.
### What changed?
#### ✳️ bun (1.1.40 → 1.1.42) · [Repo](https://github.com/oven-sh/bun)
Sorry, we couldn't find anything useful about this release.
---
[Depfu](https://depfu.com) will automatically keep this PR
conflict-free, as long as you don't add any commits to this branch
yourself. You can also trigger a rebase manually by commenting with
`@depfu rebase`.
<details><summary>All Depfu comment commands</summary>
<blockquote><dl>
<dt>@depfu rebase</dt><dd>Rebases against your default branch and
redoes this update</dd>
<dt>@depfu recreate</dt><dd>Recreates this PR, overwriting any edits
that you've made to it</dd>
<dt>@depfu merge</dt><dd>Merges this PR once your tests are passing and
conflicts are resolved</dd>
<dt>@depfu cancel merge</dt><dd>Cancels automatic merging of this
PR</dd>
<dt>@depfu close</dt><dd>Closes this PR and deletes the branch</dd>
<dt>@depfu reopen</dt><dd>Restores the branch and reopens this PR (if
it's closed)</dd>
<dt>@depfu pause</dt><dd>Ignores all future updates for this dependency
and closes this PR</dd>
<dt>@depfu pause [minor|major]</dt><dd>Ignores all future minor/major
updates for this dependency and closes this PR</dd>
<dt>@depfu resume</dt><dd>Future versions of this dependency will
create PRs again (leaves this PR as is)</dd>
</dl></blockquote>
</details>
Co-authored-by: depfu[bot] <23717796+depfu[bot]@users.noreply.github.com>
This PR ensures that if you are using an arbitrary value such as
`bg-[red` that it only compiles if it's a properly closed arbitrary
value.
Currently what happens is that it assumes the `]` is there, and cuts it
off. This then results in the `bg-[red` to be compiled as:
```css
.bg-\[red {
background-color: re;
}
```
Note how the `d` in `red` is cut off. That's the assumption that the `]`
is there.
This PR fixes that by ensuring that the arbitrary value is properly
closed.
Fixes: #15484
Here is everything you need to know about this update. Please take a
good look at what changed and the test results before merging this pull
request.
### What changed?
#### ✳️ jiti (2.4.0 → 2.4.2) · [Repo](https://github.com/unjs/jiti) ·
[Changelog](https://github.com/unjs/jiti/blob/main/CHANGELOG.md)
<details>
<summary>Release Notes</summary>
<h4><a
href="https://github.com/unjs/jiti/releases/tag/v2.4.2">2.4.2</a></h4>
<blockquote><p dir="auto"><a
href="https://bounce.depfu.com/github.com/unjs/jiti/compare/v2.4.1...v2.4.2">compare
changes</a> (📦 bundled dependencies updated)</p>
<h3 dir="auto">🩹 Fixes</h3>
<ul dir="auto">
<li>
<strong>cache:</strong> Add <code class="notranslate">+map</code> suffix
to fs entries when <code class="notranslate">sourceMaps</code> enabled
(<a
href="https://bounce.depfu.com/github.com/unjs/jiti/pull/352">#352</a>)</li>
<li>Use native require cache of loaded entries only for Node.js 22.12.+
compatibility (<a
href="https://bounce.depfu.com/github.com/unjs/jiti/pull/348">#348</a>)</li>
</ul></blockquote>
<h4><a
href="https://github.com/unjs/jiti/releases/tag/v2.4.1">2.4.1</a></h4>
<blockquote><p dir="auto"><a
href="https://bounce.depfu.com/github.com/unjs/jiti/compare/v2.4.0...v2.4.1">compare
changes</a></p>
<h3 dir="auto">🩹 Fixes</h3>
<ul dir="auto">
<li>Interop modules with primitive default export (<a
href="https://bounce.depfu.com/github.com/unjs/jiti/pull/343">#343</a>)</li>
</ul></blockquote>
<p><em>Does any of this look wrong? <a
href="https://depfu.com/packages/npm/jiti/feedback">Please let us
know.</a></em></p>
</details>
<details>
<summary>Commits</summary>
<p><a
href="2f9c2376e7...340e2a733c">See
the full diff on Github</a>. The new version differs by 9 commits:</p>
<ul>
<li><a
href="340e2a733c"><code>chore(release):
v2.4.2</code></a></li>
<li><a
href="cf952e4573"><code>fix:
use native require cache of loaded entries only (#348)</code></a></li>
<li><a
href="4dacbf1a7c"><code>fix(cache):
add `+map` suffix to fs entries when `sourceMaps` enabled
(#352)</code></a></li>
<li><a
href="0c2c0d0d5c"><code>test:
simplify snapshot tests (#351)</code></a></li>
<li><a
href="7b7ffefdde"><code>chore:
update deps</code></a></li>
<li><a
href="36d52d59c9"><code>chore(deps):
update all non-major dependencies (#344)</code></a></li>
<li><a
href="ad6191f046"><code>chore(release):
v2.4.1</code></a></li>
<li><a
href="cca319bbcd"><code>fix:
interop modules with primitive default export (#343)</code></a></li>
<li><a
href="58d3f5f8b8"><code>chore:
update deps</code></a></li>
</ul>
</details>
---
[Depfu](https://depfu.com) will automatically keep this PR
conflict-free, as long as you don't add any commits to this branch
yourself. You can also trigger a rebase manually by commenting with
`@depfu rebase`.
<details><summary>All Depfu comment commands</summary>
<blockquote><dl>
<dt>@depfu rebase</dt><dd>Rebases against your default branch and
redoes this update</dd>
<dt>@depfu recreate</dt><dd>Recreates this PR, overwriting any edits
that you've made to it</dd>
<dt>@depfu merge</dt><dd>Merges this PR once your tests are passing and
conflicts are resolved</dd>
<dt>@depfu cancel merge</dt><dd>Cancels automatic merging of this
PR</dd>
<dt>@depfu close</dt><dd>Closes this PR and deletes the branch</dd>
<dt>@depfu reopen</dt><dd>Restores the branch and reopens this PR (if
it's closed)</dd>
<dt>@depfu pause</dt><dd>Ignores all future updates for this dependency
and closes this PR</dd>
<dt>@depfu pause [minor|major]</dt><dd>Ignores all future minor/major
updates for this dependency and closes this PR</dd>
<dt>@depfu resume</dt><dd>Future versions of this dependency will
create PRs again (leaves this PR as is)</dd>
</dl></blockquote>
</details>
Co-authored-by: depfu[bot] <23717796+depfu[bot]@users.noreply.github.com>
When we were porting all of the utilities from v3 to v4 we accidentally
used the wrong names for these two classes, so this PR fixes that and
corrects them back to the names used in v3.
| Before | After |
| --- | --- |
| `bg-round` | `bg-repeat-round` |
| `bg-space` | `bg-repeat-space` |
---------
Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
Here is everything you need to know about this update. Please take a
good look at what changed and the test results before merging this pull
request.
### What changed?
#### ✳️ @types/bun (1.1.13 → 1.1.14) ·
[Repo](https://github.com/DefinitelyTyped/DefinitelyTyped)
Sorry, we couldn't find anything useful about this release.
---
[Depfu](https://depfu.com) will automatically keep this PR
conflict-free, as long as you don't add any commits to this branch
yourself. You can also trigger a rebase manually by commenting with
`@depfu rebase`.
<details><summary>All Depfu comment commands</summary>
<blockquote><dl>
<dt>@depfu rebase</dt><dd>Rebases against your default branch and
redoes this update</dd>
<dt>@depfu recreate</dt><dd>Recreates this PR, overwriting any edits
that you've made to it</dd>
<dt>@depfu merge</dt><dd>Merges this PR once your tests are passing and
conflicts are resolved</dd>
<dt>@depfu cancel merge</dt><dd>Cancels automatic merging of this
PR</dd>
<dt>@depfu close</dt><dd>Closes this PR and deletes the branch</dd>
<dt>@depfu reopen</dt><dd>Restores the branch and reopens this PR (if
it's closed)</dd>
<dt>@depfu pause</dt><dd>Ignores all future updates for this dependency
and closes this PR</dd>
<dt>@depfu pause [minor|major]</dt><dd>Ignores all future minor/major
updates for this dependency and closes this PR</dd>
<dt>@depfu resume</dt><dd>Future versions of this dependency will
create PRs again (leaves this PR as is)</dd>
</dl></blockquote>
</details>
Co-authored-by: depfu[bot] <23717796+depfu[bot]@users.noreply.github.com>
The utilities `place-content-between`, `place-content-around`, and
`place-content-evenly` are defined incorrectly. This PR fixes them.
---------
Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
We don’t want utilities like `basis-prose`, `w-prose`, etc existing nor
a `@prose:*` variant. So we’re moving the theme key to `--max-width-*`
to align with the definition as it was in v3.
cc @adamwathan
---------
Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
We recently introduced some better instrumentation
(https://github.com/tailwindlabs/tailwindcss/pull/15303) which uses the
new `using` keyword. I made sure that this was compiled correctly for
environments where `using` is not available yet.
The issue is that this also relies on `Symbol.dispose` being available.
In my testing on our minimal required Node.js version (18) it did work
fine. However, turns out that I was using `18.20.x` locally where
`Symbol.dispose` **_is_** available, but on older version of Node.js 18
(e.g.: `18.17.x`) it is **_not_** available. This now results in some
completely broken builds, e.g.: when running on Cloudflare Pages. See:
#15399
I could reproduce this error in CI, by temporarily downgrading the used
Node.js version to `18.17.0`. See:
<img width="1142" alt="image"
src="https://github.com/user-attachments/assets/5bf30f80-9ca0-40d9-ad02-d1ffb4e0e5dd"
/>
Implementing the proper polyfill, as recommended by the TypeScript docs
( see:
https://www.typescriptlang.org/docs/handbook/release-notes/typescript-5-2.html#:~:text=Symbol.dispose,-??=%20Symbol(%22Symbol.dispose
), the error goes away. (If you look at CI after the polyfill, it still
fails but for different reasons unrelated to this change)
Fixes: #15399
---
## Test plan
1. I reproduced it in CI, and I kept the commits so that you can take a
look where it fails with the `Object not disposable`.
2. Using the provided reproduction from #15399:
### Before
It works on Node.js v18.20.x, but switching to Node.js v18.17.x you can
see it fail:
<img width="1607" alt="image"
src="https://github.com/user-attachments/assets/cb6ab73a-8eb2-4003-bab7-b2390f1c879d"
/>
### After
Using pnpm's overrides, we can apply the fix from this PR and test it in
the reproduction. You'll notice that it now works in both Node.js
v18.20.x and v18.17.x
<img width="1604" alt="image"
src="https://github.com/user-attachments/assets/b3a65557-0658-4cb0-a2f9-e3079c7936d5"
/>
Resolves https://github.com/tailwindlabs/tailwindcss/discussions/15387
This PR changes the Chrome target to 111. We initially picked 120
because of the unnecessary `:dir()` down-leveling but we that was maybe
a bit too recent as it was causing some necessary prefixes to not be
generated (e.g. `-webkit-background-clip`).
This PR changes it to 111 which we require for the `color-mix()`
function. To work around the `:dir()` down-leveling we also disable the
`DirSelector` lightningcss feature which is used to control this
behavior:
https://sourcegraph.com/github.com/parcel-bundler/lightningcss/-/blob/src/selector.rs?L1964-1965
This PR renames the `--aspect-ratio` theme key to `--aspect`. This is to
match what we've done with other theme keys where they match the utility
names, like `--ease` and `--leading`.
```diff
@theme {
- --aspect-ratio-retro: 4 / 3;
+ --aspect-retro: 4 / 3;
}
```
Additionally, I've also converted the existing `aspect-video` static
utility to a theme value. This will allow people to override this
utility in their own projects—something that's not possible with static
utilities. This change feels appropriate since the video aspect ratio is
subjective, unlike other static utilities like `aspect-square`.
```css
@theme {
--aspect-video: 4 / 3; /* N64 baby! */
}
```
We changed how AST printing worked recently but forgot to update this.
Which causes us to print properties with a value of `undefined` in
Tailwind Play, Tailwind CSS IntelliSense, and our Language Server
(oops).
This PR fixes this by optimizing the AST before printing (which is what
toCss did previously)
This PR skips creating a compiler in the `@tailwindcss/postcss`
implementation if we know that the CSS file we are handling is
definitely not a Tailwind CSS file.
This is a performance improvement for initial builds where some CSS
files would've been handling by Tailwind CSS but shouldn't. E.g.: When
setting up custom fonts in Next.js applications, each font will have
it's own CSS file that is passed to `@tailwindcss/postcss`.
Since they don't contain `@import` or any other Tailwind CSS directives,
we can just skip them.
Resolves#15315
It looks like we implemented this in Core but forgot to expose it from
the distributed package (the references are only used for testing
plugins internally right now). This exposes `flattenColorPalette` under
the old import path of `tailwindcss/lib/util/flattenColorPalette`.
## Test Plan
Added the following plugin to the Vite example and ensured it works as
expected:
```ts
import flattenColorPalette from 'tailwindcss/lib/util/flattenColorPalette'
import plugin from 'tailwindcss/plugin'
export default plugin(({ matchUtilities, theme }) => {
matchUtilities(
{
'hover-bg': (value) => {
return {
'&:hover': {
backgroundColor: value,
},
}
},
},
{ values: flattenColorPalette(theme('colors')) },
)
})
```
<img width="462" alt="Screenshot 2024-12-06 at 11 47 44"
src="https://github.com/user-attachments/assets/11163390-053e-4c6e-8cb9-ae67184ad594">
Resolves#15320Resolves#15175
Turns out that the postcss file watcher does not like our Unix based
paths and will print a warning about them. This fixes the issue by
calling `path.resolve()` to convert it back to a Windows-style absolute
path if necessary.
## Test Plan
Tested on Windows with a new Next.js 14 project. Ensured that file
reloads also still work (changes to the `tsx` file are picked up
correctly). Also ensure that the CI runs on Windows.
### Before
<img width="1178" alt="Screenshot 2024-12-06 at 13 12 23"
src="https://github.com/user-attachments/assets/70c1fe45-6983-4fb4-9889-716a0cbef03a">
### After
<img width="1196" alt="Screenshot 2024-12-06 at 13 23 24"
src="https://github.com/user-attachments/assets/0b9e3ff7-c5b6-4ccb-85a9-e7ba7aee355a">
This PR improves the `@tailwindcss/postcss` integration by using direct
AST transformations between our own AST and PostCSS's AST. This allows
us to skip a step where we convert our AST into a string, then parse it
back into a PostCSS AST.
The only downside is that we still have to print the AST into a string
if we want to optimize the CSS using Lightning CSS. Luckily this only
happens in production (`NODE_ENV=production`).
This also introduces a new private `compileAst` API, that allows us to
accept an AST as the input. This allows us to skip the PostCSS AST ->
string -> parse into our own AST step.
To summarize:
Instead of:
- Input: `PostCSS AST` -> `.toString()` -> `CSS.parse(…)` -> `Tailwind
CSS AST`
- Output: `Tailwind CSS AST` -> `toCSS(ast)` -> `postcss.parse(…)` ->
`PostCSS AST`
We will now do this instead:
- Input: `PostCSS AST` -> `transform(…)` -> `Tailwind CSS AST`
- Output: `Tailwind CSS AST` -> `transform(…)` -> `PostCSS AST`
---
Running this on Catalyst, the time spent in the `@tailwindcss/postcss`
looks like this:
- Before: median time per run: 19.407687 ms
- After: median time per run: 11.8796455 ms
This is tested on Catalyst which roughly generates ~208kb worth of CSS
in dev mode.
While it's not a lot, skipping the stringification and parsing seems to
improve this step by ~40%.
Note: these times exclude scanning the actual candidates and only time
the work needed for parsing/stringifying the CSS from and into ASTs. The
actual numbers are a bit higher because of the Oxide scanner reading
files from disk. But since that part is going to be there no matter
what, it's not fair to include it in this benchmark.
---------
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
Closes#15219
This PR adds a new feature, `@import "…" reference` that can be used to
load Tailwind CSS configuration files without adding any style rules to
the CSS.
The idea is that you can use this in combination with your Tailwind CSS
root file when you need to have access to your full CSS config outside
of the main stylesheet. A common example is for Vue, Svelte, or CSS
modules:
```css
@import "./tailwind.css" reference;
.link {
@apply underline;
}
```
Importing a file as a reference will convert all `@theme` block to be
`reference`, so no CSS variables will be emitted. Furthermore it will
strip out all custom styles from the stylesheet. Furthermore plugins
registered via `@plugin` or `@config` inside reference-mode files will
not add any content to the CSS file via `addBase()`.
## Test Plan
Added unit test for when we handle the import resolution and when
`postcss-import` does it outside of Tailwind CSS. I also changed the
Svelte and Vue integration tests to use this new syntax to ensure it
works end to end.
---------
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
Closes#15138
This PR changes the postcss client to run in the `Once` hook instead of
`OnceExit`. This makes sure the postcss order in v4 matches that of v3.
Conceptually this also makes more sense, since we expect tailwindcss to
be run as one of the first plugins in the pipeline (where `OnceExit`
would run it almost at the end).
To make sure it's still possible to use `postcss-import` before and have
it resolve to the right paths, we also needed to change the
`postcss-fix-relative-paths` plugin to run in the `Once` order
(`postcss-import` also uses `Once` order so the order).
## Test Plan
This issue had many ways in which it can manifest. I added a unit test
to ensure the plugin order works but here's a concrete example when
using the postcss plugin in Vite.
### Before
Image `url()`s were not properly handled since the postcss plugin to
transform these was run before Tailwind CSS could generate the class for
it:
<img width="2532" alt="Screenshot 2024-12-02 at 14 55 42"
src="https://github.com/user-attachments/assets/2f23b409-1576-441d-9ffe-6f24ad6e7436">
### After
<img width="2529" alt="Screenshot 2024-12-02 at 14 53 52"
src="https://github.com/user-attachments/assets/b754c3d8-1af1-4aeb-87da-0bfc3ffecdb7">
---------
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
Closes#15250
This PR simplifies our Vite integration even more. It turns out that in
some projects (see #15250 for the exact repro), the way we invoke
`svelte-preprocess` was actually causing issues in Vite since with Vite,
it's expected to use the `sveltePreprocess` version exported by
`sveltejs/vite-plugin-svelte`.
While trying to change this we noticed that there are different versions
of `sveltejs/vite-plugin-svelte` for Vite 5 and Vite 6 which caused us
to investigate even more and we noticed that we do not even need to
recursively call into the `sveltePreprocess()` as every plugin is run
after each other anyways. This allows us to drop the dependency on
`svelte-preprocess` and simplify the code a bit more, registering only a
`(string) => string` style transformer.
## Test Plan
This was tsted on the repro repo from #15250 as well as the SvelteKit
setup from [my
playgrounds](https://github.com/philipp-spiess/tailwindcss-playgrounds).
Furthermore we tested various combinations of `svelte`,
`@sveltejs/vite-plugin-svelte` and `vite` in our integration test to
ensure everything works as expected.
---------
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
