)

This PR fixes an issue where `grid-cols-0` and `grid-rows-0` generated
invalid CSS. We now ensure that the value is any positive integer
(except 0).

Fixes: #16012

This PR fixes an issue where if you only used `@reference` that we
didn't process Tailwind CSS features.

We have a 'quick bail check', in the PostCSS plugin to quickly bail if
we _konw_ that we don't need to handle any Tailwind CSS features. This
is useful in Next.js applications where every single CSS file will be
passed to the PostCSS plugin.

If you use custom font ins Next.js, each of those fonts will have a CSS
file as well.

Before we introduced `@reference`, we used `@import "tailwindcss"
reference`, which passed the bail check because `@import` was being
used. Now we have `@reference` which wasn't included in the list.

This is now solved.

Fixes: #16056


### Test plan

Added a failing test that is now failing after the fix.

… (#16072)

This PR fixes an issue where tools like Prettier remove important
trailing commas in CSS variables, making gradients invalid.

We encoded the `,` in the `--tw-gradient-position` to ensure that _if_
the `var(--tw-gradient-position)` is used, that the `,` was there. And
if the variable was _not_ used that we didn't end up with a double `,,`
rendering the gradient invalid.

However, when running Prettier (there might be other tools that do this
as well), the trailing comma in the `--tw-gradient-position` was removed
which made the entire gradient invalid. E.g.:
```diff
  .bg-gradient-to-r {
-   --tw-gradient-position: to right in oklab,;
+   --tw-gradient-position: to right in oklab;
    background-image: linear-gradient(var(--tw-gradient-stops));
  }
```
Notice how the `,` is removed.

This PR fixes that, by moving the `,` to where the variable is being
used. The only side effect is that we have to guarantee that the
`--tw-gradient-position` is always present. In our testing (and using UI
tests) this should be the case.

Related Prettier issue:
prettier/prettier#17058

Fixes: #16037

Fixes #16045

This PR fixes two Vite issues found with SolidStart:

- SolidStart seems to emit an empty HTML chunk (where the content is
literally just `/`) with _no pathname_. Since we use the path to
generate an `id` for HTML chunks, this would currently cause a crash.
This was reported in #16045
- While testing the fix for the above, we also found that hot reloading
was not working in SolidStart since `4.0.0-alpha.22`. After doing some
bisecting we found that this is happening as SolidStart has the same
module ID in different servers and we were invalidating the root when we
shouldn't. After trying to restructure this code so that it only cleans
up the root when it is _no longer part of any server_, we noticed some
other compatibility issues with Nuxt and SvelteKit. It seems that the
safest bet is to no longer update a root at all during rebuilds in the
SSR step. This makes `invalidateAllRoots` a function that only notifiers
the servers about a change which is conceptually also less confusing.

## Test plan

- Added an integration test for SolidStart dev mode
- Manually tested the dev mode across all Vite based templates in
https://github.com/philipp-spiess/tailwindcss-playgrounds: Astro, Nuxt,
Remix, Solid, SvelteKit, and Vue.

---------

Co-authored-by: Robin Malfait <malfait.robin@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?




#### ✳️ turbo (2.3.3 → 2.3.4) ·
[Repo](https://github.com/turborepo/turbo)





Sorry, we couldn't find anything useful about this release.











---
![Depfu
Status](https://depfu.com/badges/edd6acd35d74c8d41cbb540c30442adf/stats.svg)

[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>

closes #16100

---------

Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
Co-authored-by: Philipp Spiess <hello@philippspiess.com>

This PR fixes na issue where `@keyframes` were emitted if they wre in a
`@theme
reference` and anothe `@theme {}` (that is not a reference) was present.

E.g.:

```css
@reference "tailwindcss";

@theme {
  /* ... */
}
```

Produces:
```css
:root, :host {
}
@Keyframes spin {
  to {
    transform: rotate(360deg);
  }
}
@Keyframes ping {
  75%, 100% {
    transform: scale(2);
    opacity: 0;
  }
}
@Keyframes pulse {
  50% {
    opacity: 0.5;
  }
}
@Keyframes bounce {
  0%, 100% {
    transform: translateY(-25%);
    animation-timing-function: cubic-bezier(0.8, 0, 1, 1);
  }
  50% {
    transform: none;
    animation-timing-function: cubic-bezier(0, 0, 0.2, 1);
  }
}
```

With this PR, the produced CSS looks like this instead:
```css
:root, :host {
}
```

Note: the empty `:root, :host` will be solved in a subsequent PR.

### Test plan

Added some unit tests, and a dedicated integration test.

This PR ensures that escaped theme variables are properly handled. We do
this by moving the `escape`/`unescape` responsibility back into the main
tailwindcss entrypoint that reads and writes from the CSS and making
sure that _all internal state of the `Theme` class are unescaped
classes.

However, due to us accidentally shipping the part where a dot in the
theme variable would translate to an underscore in CSS already, this
logic is going to stay as-is for now.

Here's an example test that visualizes the new changes:

```ts
expect(
  await compileCss(
    css`
      @theme {
        --spacing-*: initial;
        --spacing-1\.5: 2.5rem;
        --spacing-foo\/bar: 3rem;
      }
      @tailwind utilities;
    `,
    ['m-1.5', 'm-foo/bar'],
  ),
).toMatchInlineSnapshot(`
  ":root, :host {
    --spacing-1\.5: 2.5rem;
    --spacing-foo\\/bar: 3rem;
  }

  .m-1\\.5 {
    margin: var(--spacing-1\.5);
  }

  .m-foo\\/bar {
    margin: var(--spacing-foo\\/bar);
  }"
`)
```

## Test plan

- Added a unit test
- Ensure this works end-to-end using the Vite playground:
   
<img width="1016" alt="Screenshot 2025-01-30 at 14 51 05"
src="https://github.com/user-attachments/assets/463c6fd5-793f-4ecc-86d2-5ad40bbb3e74"
/>

Closes #16039

This PR changes our URL rebasing logic used with Vite so that it does
not rebase URLs that look like common alias paths (e.g. urls starting in
`~`, `@` or `#`, etc.). Unfortunately this is only an approximation and
you can configure an alias for a path that starts with a regular
alphabetical character (e.g. `foo` => `./my/foo`) so this isn't a
perfect fix, however in practice most aliases will be prefixed with a
symbol to make it clear that it's an alias anyways.

One alternative we have considered is to only rebase URLs that we know
are relative (so they need to start with a `.`). This, however, will
break common CSS use cases where urls are loaded like this:

```css
background: image-set(
  url('image1.jpg') 1x,
  url('image2.jpg') 2x
);
``` 

So making this change felt like we only trade one GitHub issue for
another one.

In a more ideal scenario we try to resolve the URL with the Vite
resolver (we have to run the resolver and can't rely on the `resolve`
setting alone due to packages like
[`vite-tsconfig-paths`](https://www.npmjs.com/package/vite-tsconfig-paths)),
however even then we can have relative paths being resolvable to
different files based on wether they were rebased or not (e.g. when an
image with the same filename exists in two different paths).

So ultimately we settled on extending the already existing blocklist
(which we have taken from the Vite implementation) for now.

## Test plan

- Added unit test and it was tested with the Vite playground.

---------

Co-authored-by: Robin Malfait <malfait.robin@gmail.com>

Fixes #16036

This adds a new rule to treat `<style>` blocks found within `.html` file
as Tailwind CSS targets.

## Test plan

- Tested using the Vite extension (dev) and a new integration test
(prod)

Co-authored-by: Robin Malfait <malfait.robin@gmail.com>

I discovered this when triaging an error someone had on Tailwind Play.

1. When we see a `;` we often assume a valid declaration precedes it but
that may not be the case
2. When we see the name of a custom property we assume everything that
follows will be a valid declaration but that is not necessarily the case
3. A bare identifier inside of a rule is treated as a declaration which
is not the case

This PR fixes all three of these by ignoring these invalid cases. Though
some should probably be turned into errors.

---------

Co-authored-by: Robin Malfait <malfait.robin@gmail.com>

This PR is an optimization where it will not emit empty rules and
at-rules. I noticed this while working on
#16120 where we emitted:
```css
:root, :host {
}
```

There are some exceptions for "empty" at-rules, such as:

```css
@charset "UTF-8";
@layer foo, bar, baz;
@Custom-Media --modern (color), (hover);
@namespace "http://www.w3.org/1999/xhtml";
```

These don't have a body, but they still have a purpose and therefore
they will be emitted.

However, if you look at this:

```css
/* Empty rule */
.foo {
}

/* Empty rule, with nesting */
.foo {
  .bar {
  }
  .baz {
  }
}

/* Empty rule, with special case '&' rules */
.foo {
  & {
    &:hover {
    }
    &:focus {
    }
  }
}

/* Empty at-rule */
@media (min-width: 768px) {
}

/* Empty at-rule with nesting*/
@media (min-width: 768px) {
  .foo {
  }

  @media (min-width: 1024px) {
    .bar {
    }
  }
}
```

None of these will be emitted.

---------

Co-authored-by: Jordan Pittman <jordan@cryptica.me>

This makes it so `@variant` is replaced at the top level and not just
within rules. This also fixes a bug where `@variant` wasn't handled when
inside an `@media` at-rule.

Co-authored-by: Adam Wathan <adam.wathan@gmail.com>