Merge next into main
#15979
Closed
Merge next into main
#15979
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…-subgrid` and `grid-rows-subgrid` (#14840) This PR adds a migration to convert `grid-cols-[subgrid]` to `grid-cols-subgrid` and `grid-rows-[subgrid]` to `grid-rows-subgrid`.
When migrating a project from Tailwind CSS v3 to Tailwind CSS v4, then we started the migration process in the following order: 1. Migrate the JS/TS config file 2. Migrate the source files (found via the `content` option) 3. Migrate the CSS files However, if you have a setup where you have multiple CSS root files (e.g.: `frontend` and `admin` are separated), then that typically means that you have an `@config` directive in your CSS files. These point to the Tailwind CSS config file. This PR changes the migration order to do the following: 1. Build a tree of all the CSS files 2. For each `@config` directive, migrate the JS/TS config file 3. For each JS/TS config file, migrate the source files If a CSS file does not contain any `@config` directives, then we start by filling in the `@config` directive with the default Tailwind CSS config file (if found, or the one passed in). If no default config file or passed in config file can be found, then we will error out (just like we do now) --------- Co-authored-by: Adam Wathan <[email protected]>
… value suffix (#14849) This PR reworks the default `--shadow-*` and `--inset-shadow-*` scales to remove the bare `shadow` and `inset-shadow` utilities, and ensure every shadow has an explicit size as part of the utility name. Here's a complete list of changes: | v3 | v4 Alpha | Proposed | | ----------------- | ----------------- | ------------------ | | _N/A_ | `shadow-xs` | `shadow-2xs` | | `shadow-sm` | `shadow-sm` | `shadow-xs` | | `shadow` | `shadow` | `shadow-sm` | | `shadow-md` | `shadow-md` | `shadow-md` | | `shadow-lg` | `shadow-lg` | `shadow-lg` | | `shadow-xl` | `shadow-xl` | `shadow-xl` | | _N/A_ | `inset-shadow-xs` | `inset-shadow-2xs` | | _N/A_ | `inset-shadow-sm` | `inset-shadow-xs` | | `shadow-inner` | `inset-shadow` | `inset-shadow-sm` | The motivation for this change is just to make the scale more predictable — it's never been intuitive to me that `shadow` sits in between `shadow-sm` and `shadow-md`. This PR doesn't remove the ability to create classes like `shadow` and `inset-shadow` by adding bare `--shadow` and `--inset-shadow` theme variables, but does remove them from the default theme. ## Impact We'll include a codemod for this in our upgrade tool to automate this change for people upgrading from v3 to v4, but this is still sort of an annoying breaking change admittedly and will make lots of educational resources, example components, and LLM tools out of date for v4 😕 At the same time I don't want to feel like we can never correct regrettable legacy decisions just to preserve backward compatibility. We made a similar change like this when we went from the v0.x color palette to the v1.x color palette changing names like `bg-red` to `bg-red-500` and that proved to definitely be the right decision long term, so want to rip the band-aid off here too if we can. Planning to make the same change for `rounded`, `drop-shadow`, and `blur` as well — maybe in separate PRs but maybe just all in this one as well since I don't think we want to do one and not all. _Update_: I've also made the same changes to the `--radius-*`, `--drop-shadow-*`, and `--blur-*` scales now, effectively removed the `rounded`, `drop-shadow`, and `blur` classes by default, and changing the meaning `rounded-sm`, `drop-shadow-sm`, and `blur-sm`. We'll put together a codemod to handle this stuff in a separate PR. --------- Co-authored-by: Adam Wathan <[email protected]>
This PR removes `--transition-timing-function-linear` from the default theme in favor of a static `ease-linear` utility. Doesn't make sense for this to be a design token since `linear` can only mean `linear`. This is consistent with how we handle basically every other similar case in the framework. --------- Co-authored-by: Adam Wathan <[email protected]>
This PR replaces the default spacing scale (`--spacing-*`) with a generative system based on a default spacing _unit_. Instead of the default theme containing values like `--spacing-4`, `--spacing-6`, `--spacing-8`, etc., instead we just define a single `--spacing` value: ```css @theme { --spacing: 0.25rem; } ``` Utilities like `px-4` are derived from this unit by multiplying it by the value in the utility (4 in this case): ```css .px-4 { padding-inline: calc(var(--spacing) * 4); } ``` The biggest consequence of this change is that every value is available now, rather than just the explicitly configured values. This means utilities like `px-42` will work now, whereas prior to this PR only `px-40` and `px-44` were valid utilities. I personally found it very difficult to know which values actually existed at the higher end of the scale without IntelliSense, and in practice even when working with a skilled designer like [Steve](https://x.com/steveschoger) who helped design Tailwind's default spacing scale, I'd very often need to break out of it to implement a design, and trying to round to a value that was in the scale made the design worse, not better. This PR allows you to use any whole number, as well as decimal numbers that are multiples of `0.25` to ensure classes like `px-1.5` continue to work. While this means you can now technically do things like `pt-97.25`, I think the presence of the fractional value will be enough of a signal to developers that they are doing something a little unusual, and they can use their judgment as to whether they are making the right decision or not. I'll update this PR with a lot more detail when I have a chance, as there are a few other things to explain like: - Unifying all of the values for width/min-width/max-width/height/min-height/max-height utilities - Deriving numeric line-height values from the spacing multiplier instead of a separate line-height scale - Using `--spacing: initial` to disable the multiplier - How you can still use an explicit spacing scale and ignore this change - How we plan to use IntelliSense to surface a more curated set of spacing values even if smaller increments work when you type them explicitly --------- Co-authored-by: Adam Wathan <[email protected]>
This PR changes how we render `var(...)` calls for theme values,
removing the fallback values we were previously including.
```diff
.text-white {
- color: var(--color-white, #fff);
+ color: var(--color-white);
}
```
We previously included the fallbacks only so you could see the value in
dev tools but this feels like a bad reason to bloat the CSS. I'd rather
just convince the Chrome team to surface this stuff better in dev tools
in the first place.
---------
Co-authored-by: Adam Wathan <[email protected]>
This PR removes all of the static `font-weight` utilities that were previously hard-coded into the framework in favor of deriving those utilities from the `--font-weight-*` theme values instead. Biggest motivation for this is giving people a way to explicitly disable font-weight utilities they don't want to use in their project, which previously wasn't possible. --------- Co-authored-by: Adam Wathan <[email protected]>
) This PR fixes an issue where some special characters (with an actual meaning CSS) were used inside of the `url(…)` function, would result in incorrectly parsed CSS. For example, when we encounter a `{`, then we would start a new "block" for nesting purposes. If we encounter an `}`, then the block would end. If we encounter a `;`, then that would be the end of a declaration. All of that is true, unless we are in a `url(…)` function. In that case, we should ignore all of those characters and treat them as part of the URL. This is only an issue because: 1. We are allowed to use these characters in URLs. 2. We can write an url inside `url(…)` without quotes. With quotes, this would not be an issue. --------- Co-authored-by: Philipp Spiess <[email protected]>
This PR adds a migration for migrating the changes we implemented in #14849 This is the migration we perform: | Old | New | | ----------------- | ------------------ | | `shadow` | `shadow-sm` | | `shadow-sm` | `shadow-xs` | | `shadow-xs` | `shadow-2xs` | | `inset-shadow` | `inset-shadow-sm` | | `inset-shadow-sm` | `inset-shadow-xs` | | `inset-shadow-xs` | `inset-shadow-2xs` | | `drop-shadow` | `drop-shadow-sm` | | `drop-shadow-sm` | `drop-shadow-xs` | | `rounded` | `rounded-sm` | | `rounded-sm` | `rounded-xs` | | `blur` | `blur-sm` | | `blur-sm` | `blur-xs` | Also added an integration test to ensure that `shadow` is properly migrated to `shadow-sm`, and doesn't get migrated to `shadow-xs` (because `shadow-sm` is migrated to `shadow-xs`).
This PR improves the generated CSS by running it through Lightning CSS twice.Right now Lightning CSS merges adjacent at-rules and at the end flattens the nesting. This means that after the nesting is flattened, the at-rules that are adjacent and could be merged together will not be merged. This PR improves our output by running Lightning CSS twice on the generated CSS which will make sure to merge adjacent at-rules after the nesting is flattened. Note: in the diff output you'll notice that some properties are duplicated. These need some fixes in Lightning CSS itself but they don't break anything for us right now. Related PR in Lightning CSS for the double `-webkit-backdrop-filter` can be found here: parcel-bundler/lightningcss#850 --------- Co-authored-by: Philipp Spiess <[email protected]>
This PR renames the `--font-family-*` theme variables to `--font-*` to more closely match the utility names and be a bit more terse in general. ```diff @theme { - --font-family-sans: ui-sans-serif, system-ui, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol', 'Noto Color Emoji'; - --font-family-serif: ui-serif, Georgia, Cambria, 'Times New Roman', Times, serif; - --font-family-mono: ui-monospace, SFMono-Regular, Menlo, Monaco, Consolas, 'Liberation Mono', 'Courier New', monospace; + --font-sans: ui-sans-serif, system-ui, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol', 'Noto Color Emoji'; + --font-serif: ui-serif, Georgia, Cambria, 'Times New Roman', Times, serif; + --font-mono: ui-monospace, SFMono-Regular, Menlo, Monaco, Consolas, 'Liberation Mono', 'Courier New', monospace; } ``` This is part of a bigger set of changes where we're renaming other theme variables as well with the same goals, since many existing theme variables like `--shadow-*` and `--radius-*` are already not using the explicit CSS property name. --------- Co-authored-by: Adam Wathan <[email protected]>
This PR renames the `--transition-timing-function-*` theme variables to `--ease-*` to more closely match the utility names and be a bit more terse in general. ```diff @theme { - --transition-timing-function-in: cubic-bezier(0.4, 0, 1, 1); - --transition-timing-function-out: cubic-bezier(0, 0, 0.2, 1); - --transition-timing-function-in-out: cubic-bezier(0.4, 0, 0.2, 1); + --ease-in: cubic-bezier(0.4, 0, 1, 1); + --ease-out: cubic-bezier(0, 0, 0.2, 1); + --ease-in-out: cubic-bezier(0.4, 0, 0.2, 1); } ``` This is part of a bigger set of changes where we're renaming other theme variables as well with the same goals, since many existing theme variables like `--shadow-*` and `--radius-*` are already not using the explicit CSS property name. --------- Co-authored-by: Adam Wathan <[email protected]>
This PR renames all of the `--width-*` variables to `--container-*` to better communicate the purpose of these tokens as layout container sizes. These are the values that were historically stored under `maxWidth` in the v3 and earlier eras, and were also re-used by the container queries plugin. The name `--container-*` feels like a better match alongside the `--breakpoint-*` namespace and since these both serve that same sort of purpose it makes sense to me that the name should be optimized for feeling "right" in that context. I like that this also sort of advertises Tailwind's support for container queries directly in the CSS variables themselves, and helps people understand what these are really intended to be used for. --------- Co-authored-by: Adam Wathan <[email protected]>
During the migration process, a lot of changes to the CSS file happen. Some parts are converted, some parts are deleted and some new CSS is added. To make sure we are generating a sensible and good looking CSS file, we will sort the final CSS and pretty print it. The order we came up with looks like this: ```css /* Imports */ @import "tailwindcss"; @import "../other.css"; /* Configuration */ @config "../path/to/tailwindcss.config.js"; @plugin "my-plugin-1"; @plugin "my-plugin-2"; @source "./foo/**/*.ts"; @source "./bar/**/*.ts"; @variant foo {} @variant bar {} @theme {} /* Border compatibility CSS */ @layer base {} /* Utilities */ @Utility foo {} @Utility bar {} /* Rest of your own CSS if any */ ``` --------- Co-authored-by: Philipp Spiess <[email protected]>
…14896) This PR fixes an issue where globs in you `content` configuration escape the current "root" of the project. This can happen if you have a folder, and you need to look up in the tree (e.g.: when looking at another package in a monorepo, or in case of a Laravel project where you want to look at mail templates). This applies a similar strategy we already implement on the Rust side. 1. Expand braces in the globs 2. Move static parts of the `pattern` to the `base` of the glob entry object --- Given a project setup like this: ``` . ├── admin │ ├── my-tailwind.config.ts │ └── src │ ├── abc.jpg │ ├── index.html │ ├── index.js │ └── styles │ └── input.css ├── dashboard │ ├── src │ │ ├── index.html │ │ ├── index.js │ │ ├── input.css │ │ └── pickaday.css │ └── tailwind.config.ts ├── package-lock.json ├── package.json ├── postcss.config.js └── unrelated └── index.html 7 directories, 14 files ``` If you then have this config: ```ts // admin/my-tailwind.config.ts export default { content: { relative: true, files: ['./src/**/*.html', '../dashboard/src/**/*.html'], // ^^ this is the important part, which escapes // the current root of the project. }, theme: { extend: { colors: { primary: 'red', }, }, }, } ``` Then before this change, running the command looks like this: <img width="1760" alt="image" src="https://github.com/user-attachments/assets/60e2dfc7-3751-4432-80e3-8b4b8f1083d4"> After this change, running the command looks like this: <img width="1452" alt="image" src="https://github.com/user-attachments/assets/5c47182c-119c-4732-a253-2dace7086049"> --------- Co-authored-by: Philipp Spiess <[email protected]>
Fixes #14784 This is an alternative to #14850 in which we actually perform url rewriting / rebasing ourselves. We ported a large portion of the URL-rewriting code from Vite (with attribution) to use here with some minor modifications. We've added test cases for the url rewriting so verifying individual cases is easy. We also wrote integration tests for Vite that use PostCSS and Lightning CSS that verify that files are found and inlined or relocated/renamed as necessary. We also did some manual testing in the Playground to verify that this works as expected across several CSS files and directories which you can see a screenshot from here: <img width="1344" alt="Screenshot 2024-11-05 at 10 25 16" src="https://github.com/user-attachments/assets/ff0b3ac8-cdc9-4e26-af79-36396a5b77b9"> --------- Co-authored-by: Philipp Spiess <[email protected]>
Fixes: #14839 Fixes: #14796 This PR fixes an issue in the Vite extension where we previously only ran a small list of allow-listed plugins for the second stage transform in the build step. This caused some CSS features to unexpectedly not work in production builds (one such example is Vue's `:deep(...)` selector). To fix this, I changed the allow listed plugins that we do want to run to a block list to filter out some plugins we know we don't want to run (e.g. the Tailwind Vite plugin for example or some built-in Vite plugins that are not necessary). ## Test plan This PR adds a new integration test suite to test interop with a custom Vite transformer that looks like this: ```js { name: 'recolor', transform(code, id) { if (id.includes('.css')) { return code.replace(/red/g, 'blue') } }, } ``` I also validated that this does indeed fix the Vue `:deep(...)` selector related issue that we were seeing by copying the repro of #14839 into our playground:  You can see in the screenshot above that the `:deep()` selector overwrites the scoped styles as expected in both the dev mode and the prod build (screenshotted). Furthermore I reproduced the issue reported in #14796 and was able to confirm that in a production build, the styling works as expected: <img width="517" alt="Screenshot 2024-11-06 at 14 26 50" src="https://github.com/user-attachments/assets/ade6fe38-be0d-4bd0-9a9a-67b6fec05ae0"> Lastly, I created a repository out of the biggest known-to-me Vite projects: [Astro, Nuxt, Remix, SolidStart, and SvelteKit](https://github.com/philipp-spiess/tailwind-playgrounds) and verified that both dev and prod builds show no issue and the candidate list is properly appended in each case. --------- Co-authored-by: Jordan Pittman <[email protected]> Co-authored-by: Adam Wathan <[email protected]>
…4906) This PR fixes an issue where unsetting `--font-*` would unset `--font-weight-*` and `--font-size-*`. ```css @theme { --font-weight-bold: bold; --font-size-sm: 14px; --font-sans: sans-serif; --font-serif: serif; } @theme { --font-*: initial; --font-body: Inter; } ``` Up until now this was sort of intended/desired behavior but with recent changes there are now more overlapping theme keys (`--inset-*` and `--inset-shadow-*` as well for example), and we don't want to make it impossible to unset _just_ the default `font-family` values. This PR also simplifies how we were handling making sure that the `inset-*` utility ignored `--inset-shadow-*` variables since it's all really the same problem. This does mean we need to maintain a list of known theme keys so we know when there is a conflict between two keys, which is kind of unfortunate because up until now this was a totally dynamic thing. End users can still add whatever custom stuff they want under `@theme` but we don't really know about those namespaces since we're maintaining a static list so we can't resolve conflicts there. I'm confident there are ways we could solve this if it actually becomes a problem, so content to push forward without solving it right now and just deal with it if/when it actually arises, because it just might not. --------- Co-authored-by: Adam Wathan <[email protected]>
This PR adds a new `**` variant to target any level of children. This is very similar to the `*` variant, the big difference is that: - `*` applies to direct children only - `**` applies to any level of children Thought of this because of all the recent work we did around globs. So a good analogy for this is glob syntax where you have the exact same difference. `*.html` vs `**/*.html`.
This PR updates all of the `--font-size-*` variables to `--text-*` instead to closer match the utility names. ```diff @theme { - --font-size-xs: 0.75rem; - --font-size-xs--line-height: 1rem; - --font-size-sm: 0.875rem; - --font-size-sm--line-height: 1.25rem; - --font-size-base: 1rem; - --font-size-base--line-height: 1.5rem; - --font-size-lg: 1.125rem; - --font-size-lg--line-height: 1.75rem; - --font-size-xl: 1.25rem; - --font-size-xl--line-height: 1.75rem; /* ... */ + --text-xs: 0.75rem; + --text-xs--line-height: 1rem; + --text-sm: 0.875rem; + --text-sm--line-height: 1.25rem; + --text-base: 1rem; + --text-base--line-height: 1.5rem; + --text-lg: 1.125rem; + --text-lg--line-height: 1.75rem; + --text-xl: 1.25rem; + --text-xl--line-height: 1.75rem; /* ... */ } ``` This is part of a bigger set of changes where we're renaming other theme variables as well with the same goals, since many existing theme variables like `--shadow-*` and `--radius-*` are already not using the explicit CSS property name. --------- Co-authored-by: Adam Wathan <[email protected]> Co-authored-by: Philipp Spiess <[email protected]> Co-authored-by: Jordan Pittman <[email protected]>
This PR adds migrations for the recent changes to the `--spacing` scale done in #12263. There are a few steps that we do to ensure we have the best upgrade experience: - If you are overwriting the `spacing` theme with custom values, we now check if the new values are multiplies of the default spacing scale. When they are, we can safely remove the overwrite. - If you are extending the `spacing` theme, we will unset the default `--spacing` scale and only use the values you provided. - Any `theme()` function calls are replaced with `calc(var(--spacing) * multiplier)` unless the values are extending the default scale. One caveat here is for `theme()` key which can not be replaced with `var()` (e.g. in `@media` attribute positions). These will not be able to be replaced with `calc()` either so the following needs to stay unmigrated: ```css @media (max-width: theme(spacing.96)) { .foo { color: red; } } ``` ## Test plan We are mainly testing two scenarios: The JS config _extends_ the `spacing` namespace and the JS config _overwrites_ the `spacing` namespace. For both cases we have added an integration test each to ensure this works as expected. The test contains a mixture of keys (some of it matching the default multiples, some don't, some have different scales, and some use non-numeric identifiers). In addition to asserting on the created CSS `@theme`, we also ensure that `theme()` calls are properly replaced. --------- Co-authored-by: Adam Wathan <[email protected]> Co-authored-by: Adam Wathan <[email protected]>
This ensures our glob hoisting mechanism (see #14896) works on Windows when performing an upgrade. --------- Co-authored-by: Jordan Pittman <[email protected]>
…#14911) This PR fixes an issue where utilities like `px` would read the `--spacing` variable and use its value as the utility value, similar to how `shadow` reads `--shadow` by default. That doesn't make sense for these utilities since `--spacing` is reserved as a special multiplier variable. --------- Co-authored-by: Adam Wathan <[email protected]>
In c5b6df2 we upgraded `lightningcss` which caused `pnpm install` to fail for me because the patch no longer worked. I re-applied the patch, doesn't seem like anything has changed in the diff (just some formatting, probably because I opened it in a new VS Code window...)
#14917) We noticed an issue that the `theme()` function wourld not properly parse in CSS if you split the argument list over multiple lines. This is fixed by treating `\n` and `\t` the same as space: ```css .custom-font { font-family: theme( fontFamily.unknown, Helvetica Neue, Helvetica, sans-serif ); } ``` ## Test plan Added tests, but also tried it in the Vite example: <img width="1995" alt="Screenshot 2024-11-08 at 13 46 09" src="https://github.com/user-attachments/assets/f9bf94b0-3f9b-4334-8911-9190987e2df5">
When using an opacity modifier such as `bg-black/[var(--opacity)]`, then
this was translated to:
```css
.bg-black\/\[var\(--opacity\)\] {
background-color: color-mix( in oklch, var(--color-black, #000) calc(var(--opacity) * 100%), transp
}
```
The issue is that this part: `calc(var(--opacity) * 100%)` is invalid
_if_ the `var(--opacity)` already contains a percentage value. See:
https://play.tailwindcss.com/xz0t
This is because this eventually resolves to `calc(20% * 100%)` and `20%
100%` is invalid in CSS.
In Catalyst we use variables like that _with_ the `%` included, which
means that v4 doesn't work as expected when using this.
A variable with a `%` included is probably the better value to support
compared to the the unit less one. This also allows you to define your
variables using `@property` as a proper `<percentage>` type.
Unfortunately the `var(--opacity)` is a value that can change at
runtime, so we don't know the type at compile time.
In the future we might be able to use `first-valid(…)` (see:
https://drafts.csswg.org/css-values-5/#f and generate both versions at
the same time.
---------
Co-authored-by: Adam Wathan <[email protected]>
This PR replaces `@variant` with `@custom-variant` for registering
custom variants via your CSS.
In addition, this PR introduces `@variant` that can be used in your CSS
to use a variant while writing custom CSS.
E.g.:
```css
.btn {
background: white;
@variant dark {
background: black;
}
}
```
Compiles to:
```css
.btn {
background: white;
}
@media (prefers-color-scheme: dark) {
.btn {
background: black;
}
}
```
For backwards compatibility, the `@variant` rules that don't have a body
and are
defined inline:
```css
@variant hocus (&:hover, &:focus);
```
And `@variant` rules that are defined with a body and a `@slot`:
```css
@variant hocus {
&:hover, &:focus {
@slot;
}
}
```
Will automatically be upgraded to `@custom-variant` internally, so no
breaking changes are introduced with this PR.
---
TODO:
- [x] ~~Decide whether we want to allow multiple variants and if so,
what syntax should be used. If not, nesting `@variant <variant> {}` will
be the way to go.~~ Only a single `@variant <variant>` can be used, if
you want to use multiple, nesting should be used:
```css
.foo {
@variant hover {
@variant focus {
color: red;
}
}
}
```
…ules (#15689) Variants like this can't be easily negated by our current system: ```css @custom-variant dark { &.is-dark { @slot; } @media (prefers-color-scheme: dark) { @slot; } } ``` Right now it produces the following CSS which is logically incorrect: ```css .utility-name { &:not(.is-dark) { /* ... */ } @media not (prefers-color-scheme: dark) { /* ... */ } } ``` The correct CSS is this which requires moving things around: ```css .utility-name { @media not (prefers-color-scheme: dark) { &:not(.is-dark) { /* ... */ } } } ``` We're opting to disable this instead of generating incorrect CSS for now. I'd like to bring this back in the future for simpler cases in the future.
This PR adds `outline-color` to the transition-property again, and updates the implementation for `outline-hidden`. The `outline-hidden` will behave exactly the same as `outline-none` _except_ in forced colors mode. In forced colors mode, `outline-hidden` will force a 2px solid border. Closes: #15591
Co-authored-by: Adam Wathan <[email protected]>
`none` is not a valid value for `min-width` or `min-height` according to [the CSS spec](https://www.w3.org/TR/css-sizing-3/#min-size-properties): > | | | > | --- | --- | > | [Value](https://www.w3.org/TR/css-values/#value-defs): | auto \| [<length-percentage>](https://www.w3.org/TR/css-values-4/#typedef-length-percentage) \| min-content \| max-content \| fit-content([<length-percentage>](https://www.w3.org/TR/css-values-4/#typedef-length-percentage)) | I believe we should be able to remove the `min-w-none` and `min-h-none` class candidates since they wouldn't have done anything anyway and thus should not affect backwards compatibility. Indeed, these did not exist in v3 either: https://github.com/tailwindlabs/tailwindcss/blob/4f9f603e12b51cc53b8a09c7739b8f88c8eb87eb/stubs/config.full.js#L674-L684 https://github.com/tailwindlabs/tailwindcss/blob/4f9f603e12b51cc53b8a09c7739b8f88c8eb87eb/stubs/config.full.js#L685-L691 --- Credit to `@i` on Discord for spotting this[^1], fixes #15846 [^1]: https://discord.com/channels/486935104384532500/486935104384532502/1332680061144403968 --------- Co-authored-by: Adam Wathan <[email protected]>
This PR makes sure all v3 and earlier versions are visible in the changelog as well as the v4 changelog entries.
This PR fixes an issue where we didn't always correctly validated
invalid CSS variables when using the CSS variable shorthand syntax.
This PR fixes that by ensuring we start with `--`. We can't validate
that the variable exists at runtime, but we can validate if it looks
like a valid CSS variable.
We can go a step further by validating if the CSS variable is valid
syntax (e.g.: all characters are valid), but we can introduce this if
this is causing actual issues in projects.
```
p-(a-b)
```
Used to compile to:
```css
.p-\(a-b\) {
padding: var(a-b);
}
```
But not anymore.
Update the `open` variant to addtionally match the new `:open` pseudo class. See spec at https://drafts.csswg.org/selectors-4/#open-state See Chromium intent to ship: https://groups.google.com/a/chromium.org/g/blink-dev/c/Pdo4oOXYKcA `:open` matches open `<details>` and `<dialog>` elements (already covered by [open]), but also matches select elements with their picker open and inputs with their picker open. Thanks to `:is()` taking a forgiving selector list, this is safe to add even with limited browser support. Co-authored-by: Robin Malfait <[email protected]>
…none` (#15921) This PR fixes an issue where classes such as `text-sm/none` don't work as expected. The reason for this is that `leading-none` is the only hardcoded leading utility and is not coming from the `@theme`. This means that `text-sm/none` tries to do a lookup for `none` but it won't resolve. This PR fixes that by allowing `none` as a modifier. While working on this, I noticed that `text-sm/none` _did_ generate CSS: ```css .text-sm\/none { font-size: var(--text-sm); } ``` Notice that the `line-height` is missing. This means that any modifier that can't be resolved doesn't get the `line-height` set, but it _will_ generate CSS. In this case, no CSS should have been generated. Otherwise, all of these generate CSS which will only bloat your CSS and won't work as expected. E.g.: `text-sm/foo`, `text-sm/bar`, and `text-sm/baz`: ```css .text-sm\/bar { font-size: var(--text-sm); } .text-sm\/baz { font-size: var(--text-sm); } .text-sm\/foo { font-size: var(--text-sm); } ``` Fixes: #15911
Closes #15220 This PR fixes an issue where the upgrade tool would not be able to load some JavaScript config files across different drive letters on Windows. The issue in detail is that `path.relative(…)` tries to build a relative path but if the file is inside the same folder, it won't start the relative path with a `./` so we manually appended it in case that it isn't there. The issue on Windows specifically is that `file.relative(…)` can also return a legit absolute path, e.g. when the file is on a different drive. In this case we obviously don't want to prefix a path with `./`. ## Test plan To reproduce this issue, I checked out a Tailwind v3 project _on a different drive letter than my Windows installation_. In that case, I was adding a repo inside `D:` while `npm` was installed in `C:`. I then run `npx @tailwindcss/upgrade` to reproduce the issue. The fix was validated with a local `bun` run of the upgrade tool: 
Now that Tailwind CSS v4 is released, we can setup a proper release workflow again. This setup mimics the workflow of how we did it in v3, but adjusted to make it work on the v4 codebase. Whenever a PR is merged into the `next` branch, we will publish an insiders release to npm using the following version number: `0.0.0-insiders.<commit-hash>`. Note: insiders releases will not have a GitHub release associated with them, therefore the `standalone-cli` won't be available as an insiders release. For the normal release procedure, the following steps are required: 1. Manually version the packages (e.g.: `pnpm run version-packages`) 2. Create a git tag for the version you want to release 3. Push the updated package.json files and the git tag to the repository Next, a GitHub action will kick in once a `tag` is being pushed. The GitHub action will run a build, and create a draft release on GitHub that will contain: 1. The CHANGELOG.md contents for the last version 2. The `standalone-cli` artifacts attached to the drafted release Once you are happy with the draft, you can publish the draft on GitHub. This in turn will trigger another GitHub action that will publish the packages to npm. Whenever an insiders release or a normal release completes, we will also trigger Tailwind Play, to update its dependencies to the latest version of Tailwind CSS. --- Note: some of the GitHub Action workflows still refer to the `next` branch instead of the `main` branch. If we later today want to get a new release out, we can merge `next` into `main` and update the workflows accordingly. --- This is hard to test, but I started from the existing release.yml file and adjusted things accordingly. The biggest change is related to the insiders version. If you look at this temporary [commit](572dddf), you can see that the publishing (dry-run) seems to work as expected: <img width="1508" alt="image" src="https://github.com/user-attachments/assets/c075e788-dcbc-4200-aa32-2b9a3c54d629" />
This PR ensures we set the version before running the build. Otherwise the embedded version number is incorrect.
This PR fixes a few problems with IntelliSense: - Default installs suggest font weight utilities twice - When setting `--font-weight-*: initial;` the default weights are still suggested - Setting `--spacing-*: initial;` still shows suggestions for utilities using the spacing scale assuming it's multiplier-based. Removing the `--spacing: …` key should make them entirely theme driven instead. - The default container query variants like `@sm`, `@md`, etc… aren't suggested. Only the `@min-sm` and `@max-sm` style ones are. Fixes tailwindlabs/tailwindcss-intellisense#1133 Fixes tailwindlabs/tailwindcss-intellisense#1136 Fixes #15811 --------- Co-authored-by: Robin Malfait <[email protected]>
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? #### ✳️ eslint-config-next (15.1.3 → 15.1.4) Sorry, we couldn't find anything useful about this release. #### ✳️ next (15.1.3 → 15.1.4) · [Repo](https://github.com/vercel/next.js) <details> <summary>Release Notes</summary> <h4><a href="https://github.com/vercel/next.js/releases/tag/v15.1.4">15.1.4</a></h4> <blockquote><div class="markdown-alert markdown-alert-note" dir="auto"> <p class="markdown-alert-title" dir="auto"><svg class="octicon octicon-info mr-2" viewbox="0 0 16 16" version="1.1" width="16" height="16" aria-hidden="true"><path d="M0 8a8 8 0 1 1 16 0A8 8 0 0 1 0 8Zm8-6.5a6.5 6.5 0 1 0 0 13 6.5 6.5 0 0 0 0-13ZM6.5 7.75A.75.75 0 0 1 7.25 7h1a.75.75 0 0 1 .75.75v2.75h.25a.75.75 0 0 1 0 1.5h-2a.75.75 0 0 1 0-1.5h.25v-2h-.25a.75.75 0 0 1-.75-.75ZM8 6a1 1 0 1 1 0-2 1 1 0 0 1 0 2Z"></path></svg>Note</p> <p dir="auto">This release is backporting bug fixes. It does <strong>not</strong> include all pending features/changes on canary.</p> </div> <h3 dir="auto">Core Changes</h3> <ul dir="auto"> <li>backport: force module format for virtual client-proxy (<a href="https://bounce.depfu.com/github.com/vercel/next.js/pull/74608">#74608</a>)</li> <li>Fix prerender tags when notFound is called (<a href="https://bounce.depfu.com/github.com/vercel/next.js/pull/74607">#74607</a>)</li> <li>Use provided waitUntil for pending revalidates (<a href="https://bounce.depfu.com/github.com/vercel/next.js/pull/74604">#74604</a>)</li> <li>Feature: next/image: add support for images.qualities in next.config (<a href="https://bounce.depfu.com/github.com/vercel/next.js/pull/74588">#74588</a>)</li> <li>Chore: docs: add missing search: '' on remotePatterns (<a href="https://bounce.depfu.com/github.com/vercel/next.js/pull/74587">#74587</a>)</li> <li>Chore: docs: update version history of next/image (<a href="https://bounce.depfu.com/github.com/vercel/next.js/pull/73923">#73923</a>) (<a href="https://bounce.depfu.com/github.com/vercel/next.js/pull/74570">#74570</a>)</li> <li>Chore: next/image: improve imgopt api bypass detection for unsupported images (<a href="https://bounce.depfu.com/github.com/vercel/next.js/pull/74569">#74569</a>)</li> </ul> <h3 dir="auto">Credits</h3> <p dir="auto">Huge thanks to @ and @ for helping!</p></blockquote> <p><em>Does any of this look wrong? <a href="https://depfu.com/packages/npm/next/feedback">Please let us know.</a></em></p> </details> <details> <summary>Commits</summary> <p><a href="https://github.com/vercel/next.js/compare/4cbaaa118d2138edd32263da0dc4b2ecb9ddbc2b...48f2588b0fea2bffb5bf6534169ee112438786a6">See the full diff on Github</a>. The new version differs by 8 commits:</p> <ul> <li><a href="https://github.com/vercel/next.js/commit/48f2588b0fea2bffb5bf6534169ee112438786a6"><code>v15.1.4</code></a></li> <li><a href="https://github.com/vercel/next.js/commit/dcb208e2603559d276a2a87f90fb2c2125e99900"><code>backport: force module format for virtual client-proxy (#74162) (#74608)</code></a></li> <li><a href="https://github.com/vercel/next.js/commit/6f6766a255d03a8b9a6b6a092c3c40cc3145f61e"><code>Fix prerender tags when notFound is called (#74577) (#74607)</code></a></li> <li><a href="https://github.com/vercel/next.js/commit/a46f27f59a4ce8b1b61cd37eaacdb0b1937e5d74"><code>Use provided waitUntil for pending revalidates (#74164) (#74604)</code></a></li> <li><a href="https://github.com/vercel/next.js/commit/bc6acf62178f7f7d2650bdf0ef054d5ef7a28386"><code>feat(next/image): add support for `images.qualities` in next.config (#74588)</code></a></li> <li><a href="https://github.com/vercel/next.js/commit/d253ac5c57b2a126944caa21006770e67456e349"><code>chore(docs): add missing `search: ''` on `remotePatterns` (#73925) (#74587)</code></a></li> <li><a href="https://github.com/vercel/next.js/commit/7b195a82a5f95ca32748852fe506a7949b885b25"><code>chore(docs): update version history of `next/image` (#73923) (#74570)</code></a></li> <li><a href="https://github.com/vercel/next.js/commit/5a501d37caefacef8899bf6925ec0252624b4dc5"><code>chore(next/image): improve imgopt api bypass detection for unsupported images (#74569)</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> Co-authored-by: Philipp Spiess <[email protected]>
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.43 → 1.2.0) · [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>
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/react-dom (19.0.2 → 19.0.3) · [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>
Resolves #15977 Our `@tailwindcss/browser` build is intended to run inside a `<script>` tag inside browsers. Because of how variable assignment within `<script>` tags work, all variables that were defined within that script are currently assigned on the global namespace. This is especially troublesome as eslint uses `$` as a valid mangling character so importing the CDN build would now redefine `globalThis.$` which collides with many very popular JavaScript libraries. In order to avoid polluting the global namespace, this PR changes the build step to emit an IIFE (so all vars defined are scroped to the function closure instead of the global namespace). ## Test plan - Ensure UI tests still work - <img width="533" alt="Screenshot 2025-01-28 at 16 49 27" src="https://github.com/user-attachments/assets/1e027451-f58b-4252-bf97-c016a90eb78b" />
This reverts commit d66d7ab.
Right now, when Oxide is scanning for files, it considers ignore files in the "root" directory it is scanning as well as all parent directories. We honor .gitignore files even when not in a git repo as an optimization in case a project has been created, contains a .gitignore, but no repo has actually been initialized. However, this has an unintended side effect of including ignore files _ouside of a repo_ when there is one. This means that if you have a .gitignore file in your home folder it'll get applied even when you're inside a git repo which is not what you'd expect. This PR addresses this by checking to see the folder being scanned is inside a repo and turns on a flag that ensures .gitignore files from the repo are the only ones used (global ignore files configured in git still work tho). This still needs lots of tests to make sure things work as expected. Fixes #15876 --------- Co-authored-by: Robin Malfait <[email protected]>
Fixes #15632 Fixes #15740 This PR fixes a number of Oxide scanner bugs reported over various channels, specifically: - When using the Svelte class shorthand split over various lines, we weren't extracting class names properly: ```svelte <div class:underline={isUnderline}> </div> ``` - We now extract classes when using the class shortcut in Angular: ```html <div [class.underline]=\"bool\"></div> ``` - We now validate parentheses within arbitrary candidates so that we don't consume invalid arbitrary candidates anymore which allows us to parse the following case properly: ```js const classes = [wrapper("bg-red-500")] ``` ## Test plan Added unit tests --------- Co-authored-by: Robin Malfait <[email protected]> Co-authored-by: Jordan Pittman <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Merge
nextintomain.