Fixes#16799
This was caused by a wrong condition in the CSS value parser that put
child function arguments into the parent function by accident.
## Test plan
- Added a unit test to guard against regressions
- Validated against the repro:
<img width="914" alt="Screenshot 2025-02-25 at 16 31 14"
src="https://github.com/user-attachments/assets/f5fdf2e7-9c1b-4b04-89a8-1fa78a27f0f5"
/>
This PR ensures we bundle the relevant JS APIs in the Standalone CLI
like `tailwindcss`, `tailwindcss/plugin`, `tailwindcss/colors`, etc…
Before, when loading plugins or configs, imports for those resources
would fail.
Fixes#15235
---------
Co-authored-by: Philipp Spiess <hello@philippspiess.com>
Fixes#16725
When using `@reference "tailwindcss";` inside a separate CSS root (e.g.
Svelte `<style>` components, CSS modules, etc.), we have no guarantee
that the CSS variables will be defined in the main stylesheet (or if
there even is one). To work around potential issues with this we decided
in #16676 that we would emit all used CSS variables from the `@theme`
inside the `@reference` block.
However, this is not only a bit surprising but also unexpected in CSS
modules and Next.js that **requires CSS module files to only create
scope-able declarations**. To fix this issue, we decided to not emit CSS
variables but instead ensure all `var(…)` calls we create for theme
values in reference mode will simply have their fallback value added.
This ensures styles work as-expected even if the root Tailwind file does
not pick up the variable as being used or _if you don't add a root at
all_. Furthermore we do not duplicate any variable declarations across
your stylesheets and you still have the ability to change variables at
runtime.
## Test plan
- Updated snapshots everywhere (see diff)
- New Next.js CSS modules integration test
Fixes#16732
If we can not get the mtime from a file, chances are that the resource
is a virtual module. This is perfectly legit and we can fall back to
what we did before the changes in `4.0.8` (which is to rebuild the root
every time a change contains a dependency like that).
## Test plan
Added a test to mimic the setup from the repor in #16732. Also ensured
the repro now passes:
<img width="1278" alt="Screenshot 2025-02-24 at 17 29 38"
src="https://github.com/user-attachments/assets/d111273d-579f-44c2-82f5-aa32d6a1879a"
/>
Note that importing virtual modules directly in CSS does not work as the
resolver we use does not resolve against the Vite runtime it seems. This
is unrelated to the regression added in `4.0.8` though and something to
look into in the future.
Add a variant for the
[`inverted-colors`](https://developer.mozilla.org/en-US/docs/Web/CSS/@media/inverted-colors)
media query.
This has been supported in Safari for a while. I'm also implementing
support in Chrome atm.
I've decided to only add the inverted-colors: inverted variant because
the `none` state isn't really useful.
---------
Co-authored-by: Philipp Spiess <hello@philippspiess.com>
Related discussion #12127
```css
.wrap-anywhere {
overflow-wrap: anywhere;
}
```
### Updated 2024-11-30
The new changes remove the original `@supports` because I agree that
developers should decide for themselves whether to maintain backward
compatibility. Also updated in line with the new changes in the `next`
branch.
---------
Co-authored-by: Philipp Spiess <hello@philippspiess.com>
<!--
👋 Hey, thanks for your interest in contributing to Tailwind!
**Please ask first before starting work on any significant new
features.**
It's never a fun experience to have your pull request declined after
investing a lot of time and effort into a new feature. To avoid this
from happening, we request that contributors create an issue to first
discuss any significant new features. This includes things like adding
new utilities, creating new at-rules, or adding new component examples
to the documentation.
https://github.com/tailwindcss/tailwindcss/blob/master/.github/CONTRIBUTING.md
-->
---------
Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
Right now we sort the nodes based on a pre-defined sort order based on
the properties that are being used. The property sort order is defined
in a list we maintain.
We also have to make sure that the property count is taken into account
such that if all the "sorts" are the same, that we fallback to the
property count. Most amount of properties should be first such that we
can override it with more specific utilities that have fewer properties.
However, if a property doesn't exist, then it wouldn't be included in a
list of properties therefore the total count was off.
This PR fixes that by counting all the used properties. If a property
already exists it is counted twice. E.g.:
```css
.foo {
color: red;
&:hover {
color: blue;
}
}
```
In this case, we have 2 properties, not 1 even though it's the same
`color` property.
## Test plan:
1. Updated the tests that are now sorted correctly
2. Added an integration test to make sure that `prose-invert` is defined
after the `prose-stone` classes when using the `@tailwindcss/typography`
plugin where this problem originated from.
Note how in this play (https://play.tailwindcss.com/wt3LYDaljN) the
`prose-invert` comes _before_ the `prose-stone` which means that you
can't apply the `prose-invert` classes to invert `prose-stone`.
Closes#16374
Ensure we don't remove custom properties from within `@keyframe`
declarations.
---------
Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
Co-authored-by: Philipp Spiess <hello@philippspiess.com>
This PR re-enables the changes necessary to remove unused theme
variables and keyframes form your CSS.
This change was initially landed as #16211 and then later reverted in
#16403 because we found some unexpected interactions with using `@apply`
and CSS variables in multi-root setups like CSS modules or Vue inline
`<style>` blocks that were no longer seeing their required variables
defined.
This issue is fixed by now ensuring that theme variables that are
defined within an `@reference "…"` boundary will still be emitted in the
generated CSS when used (as this would otherwise not generate a valid
stylesheet).
So given the following input CSS:
```css
@reference "tailwindcss";
.text-red {
@apply text-red-500;
}
```
We will now compile this to:
```css
@layer theme {
:root, :host {
--text-red-500: oklch(0.637 0.237 25.331);
}
}
.text-red {
color: var(--text-red-500);
}
```
This PR also improves the initial implementation to not mark theme
variables as used if they are only used to define other theme variables.
For example:
```css
@theme {
--font-sans:
ui-sans-serif, system-ui, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol',
'Noto Color Emoji';
--font-mono:
ui-monospace, SFMono-Regular, Menlo, Monaco, Consolas, 'Liberation Mono', 'Courier New',
monospace;
--default-font-family: var(--font-sans);
--default-mono-font-family: var(--font-mono);
}
.default-font-family {
font-family: var(--default-font-family);
}
```
This would be reduced to the following now as `--font-mono` is only used
to define another variable and never used outside the theme block:
```css
:root, :host {
--font-sans:
ui-sans-serif, system-ui, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol',
'Noto Color Emoji';
--default-font-family: var(--font-sans);
}
.default-font-family {
font-family: var(--default-font-family);
}
```
## Test plan
- See updated unit and integration tests
- Validated it works end-to-end by using a SvelteKit example
This PR improves the developer experience when trying to use `theme(…)`
options on an import.
Today, if you want to use Tailwind CSS, you can import it as:
```css
@import "tailwindcss";
```
But if you want to use any of the `theme(…)` options, like the `static`
theme option, then you had to use this instead:
```css
@layer theme, base, components, utilities;
@import 'tailwindcss/theme' layer(theme) theme(static);
@import 'tailwindcss/preflight' layer(base);
@import 'tailwindcss/utilities' layer(utilities);
```
In this scenario you have to be careful, because the `layer(…)` _must_
be the first option after an import (according to the spec). So if you
use `@import 'tailwindcss/theme' theme(static) layer(theme);` then
that's not going to work either.
This PR solves that by allowing you to use the `theme(…)` options
directly on the `@import` statement:
```css
@import 'tailwindcss' theme(static);
```
The only edge case is when you want to use `theme(reference)`. A typical
use case is for projects with `<style>` blocks where you want to
_reference_ the CSS variables from the theme.
If you use `@import 'tailwindcss' theme(reference);`, then all `@theme`
blocks will be references and you can reference theme values. This is
good. The bad part is that `@import 'tailwindcss';` also includes
preflight CSS. This means that we will import the preflight CSS for
every `<style>` block. This is probably not what you want.
The solution is to use `@reference 'tailwindcss';` instead which strips
all of that information and only gives you access to CSS variables.
This PR also makes sure that if you use `theme(reference)` on an import
that we still throw an error and suggest you use `@reference` instead.
This is not a breaking change because right now if you use `@import`
with `theme(…)` options it will already throw an error.
### Test plan:
1. Added dedicated tests to make sure we don't throw anymore.
2. Added test to make sure that we _do_ throw when using
`theme(reference)` on an import.
Alternative to #16425Fixes#16585Fixes#16389Fixes#16252Fixes#15794Fixes#16646Fixes#16358
This PR changes the Vite plugin to use the file-system to discover
potential class names instead of relying on the module-graph. This comes
after a lot of testing and various issue reports where builds that span
different Vite instances were missing class names.
Because we now scan for candidates using the file-system, we can also
remove a lot of the bookkeeping necessary to make production builds and
development builds work as we no longer have to change the resulting
stylesheet based on the `transform` callbacks of other files that might
happen later.
This change comes at a small performance penalty that is noticeable
especially on very large projects with many files to scan. However, we
offset that change by fixing an issue that I found in the current Vite
integration that did a needless rebuild of the whole Tailwind root
whenever any source file changed. Because of how impactful this change
is, I expect many normal to medium sized projects to actually see a
performance improvement after these changes. Furthermore we do plan to
continue to use the module-graph to further improve the performance in
dev mode.
## Test plan
- Added new integration tests with cases found across the issues above.
- Manual testing by adding a local version of the Vite plugin to repos
from the issue list above and the [tailwindcss
playgrounds](https://github.com/philipp-spiess/tailwindcss-playgrounds).
This PR fixes an issue where `!important` is added to declarations that
define CSS variables. The `!important` should only be added to the other
declarations.
Before:
```css
.ease-out\! {
--tw-ease: var(--ease-out) !important;
transition-timing-function: var(--ease-out) !important;
}
```
After:
```css
.ease-out\! {
--tw-ease: var(--ease-out);
transition-timing-function: var(--ease-out) !important;
}
```
Fixes: https://github.com/tailwindlabs/tailwindcss/issues/16664
This PR fixes an issue where installing a specific version of
`@tailwindcss/postcss` and `tailwindcss` could still result in a version
mismatch. This is because we were relying on `^4.0.6` for example
instead of `4.0.6`.
This PR now pins all these versions to prevent this:
```
❯ pnpm why tailwindcss
devDependencies:
@tailwindcss/postcss 4.0.5
├─┬ @tailwindcss/node 4.0.6
│ └── tailwindcss 4.0.6
└── tailwindcss 4.0.5
```
Closes#16171
This PR handles `darkMode` variant configs containing braces (so
creating sub-rules) the same way we handle it in the interop layer.
Since the interop layer runs inside the `addVariant` API that we do not
run here, I instead oped to copy the one liner.
## Test plan
Updated one of the migration tests to include a rule that wasn't working
before. Ensured the new output works via
https://play.tailwindcss.com/nR99uhKtv3
Closes#16391
Like the title suggest this PR adds error reporting when the `npm
install` or `npm remove` commands fail.
## Test plan
Tested by swapping out the command for `echo "bla"; exit 1` and
capturing the output from the integration tests:
<img width="792" alt="Screenshot 2025-02-13 at 14 33 02"
src="https://github.com/user-attachments/assets/d1288114-106a-4ac6-a54b-d02b74c98f35"
/>
<img width="761" alt="Screenshot 2025-02-13 at 14 31 05"
src="https://github.com/user-attachments/assets/6d5b9427-457f-4e67-9723-4e340da61749"
/>
Decided not to add a new test for this since it's unlikely we'll do big
changes here and the upgrade integration tests are already quite slow.
Closes#16209
This PR exposes the following types that were accessible via
`tailwindcss/types/config` in v3 now via the `tailwindcss/plugin`
export:
```ts
import type {Cofig, PluginAPI, PluginCreator, PluginsConfig, ThemeConfig } from 'tailwindcss/plugin'
```
Note that these types will not be the same as the v3 and just
approximations, however it should be enough to upgrade plugins to work
with v4.
## Test plan
Tested in a standalone project importing a dev build of tailwindcss:
<img width="1784" alt="Screenshot 2025-02-13 at 14 50 48"
src="https://github.com/user-attachments/assets/27c04666-0106-414d-ba25-1a853f9d53d1"
/>
Fixes#16461
Ensure we also emit `@property --tw-drop-shadow`.
## Test plan
```
<div class="drop-shadow-2xl size-72 bg-white">
<div class="size-48 saturate-100 bg-white"></div>
</div>
```
now only drops one shadow (screenshot from Vite playground):
<img width="562" alt="Screenshot 2025-02-12 at 16 37 25"
src="https://github.com/user-attachments/assets/94eaaf54-6fd5-4d10-9297-9e7523a02602"
/>
Closes https://github.com/tailwindlabs/tailwindcss.com/issues/2073
This ensures that we can customize `outline` via
`--default-outline-width` just like `ring`, `border`, and other
utilities.
## Test plan
Added unit tests for `--default-outline-width` and
`--default-ring-width`
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.16 → 1.2.2) ·
[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>
Fixes
https://github.com/tailwindlabs/tailwindcss-intellisense/issues/1184
The alpha and beta releases used `_` in theme keys to represent a `.`.
This meant we used `--leading-1_5` instead of `--leading-1\.5` to add
utilities like `leading-1.5`. We prefer the use of the escaped dot now
but still want to make sure suggestions for the legacy key format still
works as expected when surrounded by numbers.
When sorting utilities it was possible for a utility like `duration-700`
to come before `duration-75` or `duration-1000` to come before
`duration-150`.
This PR fixes this behavior by reading the full "magnitude" of each
numbers before we compare them.
This reverts #16211
We found some unexpected interactions with using `@apply` and CSS
variables in multi-root setups like CSS modules or Vue inline `<style>`
blocks that were broken due to that change. We plan to re-enable this
soon and include a proper fix for those scenarios.
## Test plan
- Updated snapshots
- Tested using the CLI in a new project:
<img width="1523" alt="Screenshot 2025-02-10 at 13 08 42"
src="https://github.com/user-attachments/assets/defe0858-adb3-4d61-9d2c-87166558fd68"
/>
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
This PR bumps the Prettier dependencies, and also pins the version.
Noticed that a PR with a single empty commit started failing at the time
of writing this
(https://github.com/tailwindlabs/tailwindcss/pull/16306). This is
because prettier released a new minor version which results in slightly
different output.
Let's bump prettier and handle the differences, but also pin the version
to avoid this in the future.
<!--
👋 Hey, thanks for your interest in contributing to Tailwind!
**Please ask first before starting work on any significant new
features.**
It's never a fun experience to have your pull request declined after
investing a lot of time and effort into a new feature. To avoid this
from happening, we request that contributors create an issue to first
discuss any significant new features. This includes things like adding
new utilities, creating new at-rules, or adding new component examples
to the documentation.
https://github.com/tailwindcss/tailwindcss/blob/master/.github/CONTRIBUTING.md
-->
---------
Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
Fixes#16298
This PR fixes an issue where using an AST walk in combination with
`replaceNode` and various `SkipAction` would either cause children to be
visited multiple times or not visited at all even though it should. This
PR fixes the issue which also means we can get rid of a custom walk for
`@variant` inside the `@media` that was used to apply `@variant` because
we never recursively visited children inside the `@media` rule.
Because we now can use the regular walk for `@variant`, we now properly
convert `@variant` to `@custom-variant` inside `@reference`-ed
stylesheet which also fixes#16298
## Test plan
Lots of tests added to ensure the combinations of `WalkAction` and
`replaceWith()` works as expected.
Closes#15181
This PR changes the Standalone builds to use bun baseline instead. This
compiles to a reduced instruction set and should work around the
compatibility issues experienced across older server hardware.
## Test plan
See
https://github.com/tailwindlabs/tailwindcss/issues/15181#issuecomment-2634621266
Also tested it with the repor from @npezza93 and it now works locally as
well with a Docker build.
