wrapper/tailwindcss
1
0
Fork 0
Code Issues Pull requests Projects Releases 1 Packages Wiki Activity Actions
tailwindcss/packages/@tailwindcss-upgrade/package.json

53 lines
1.3 KiB
JSON
Raw Normal View History

Add initial codemod tooling (#14434) This PR adds some initial tooling for codemods. We are currently only interested in migrating CSS files, so we will be using PostCSS under the hood to do this. This PR also implements the "migrate `@apply`" codemod from #14412. The usage will look like this: ```sh npx @tailwindcss/upgrade ``` You can pass in CSS files to transform as arguments: ```sh npx @tailwindcss/upgrade src/**/*.css ``` But, if none are provided, it will search for CSS files in the current directory and its subdirectories. ``` ≈ tailwindcss v4.0.0-alpha.24 │ No files provided. Searching for CSS files in the current │ directory and its subdirectories… │ Migration complete. Verify the changes and commit them to │ your repository. ``` The tooling also requires the Git repository to be in a clean state. This is a common convention to ensure that everything is undo-able. If we detect that the git repository is dirty, we will abort the migration. ``` ≈ tailwindcss v4.0.0-alpha.24 │ Git directory is not clean. Please stash or commit your │ changes before migrating. │ You may use the `--force` flag to override this safety │ check. ``` --- This PR alsoo adds CSS codemods for migrating existing `@apply` directives to the new version. This PR has the ability to migrate the following cases: --- In v4, the convention is to put the important modifier `!` at the end of the utility class instead of right before it. This makes it easier to reason about, especially when you are variants. Input: ```css .foo { @apply !flex flex-col! hover:!items-start items-center; } ``` Output: ```css .foo { @apply flex! flex-col! hover:items-start! items-center; } ``` --- In v4 we don't support `!important` as a marker at the end of `@apply` directives. Instead, you can append the `!` to each utility class to make it `!important`. Input: ```css .foo { @apply flex flex-col !important; } ``` Output: ```css .foo { @apply flex! flex-col!; } ```
2024-09-18 16:45:43 +02:00
{
"name": "@tailwindcss/upgrade",
4.3.1 (#20226)
2026-06-12 19:33:35 +02:00
"version": "4.3.1",
Add initial codemod tooling (#14434) This PR adds some initial tooling for codemods. We are currently only interested in migrating CSS files, so we will be using PostCSS under the hood to do this. This PR also implements the "migrate `@apply`" codemod from #14412. The usage will look like this: ```sh npx @tailwindcss/upgrade ``` You can pass in CSS files to transform as arguments: ```sh npx @tailwindcss/upgrade src/**/*.css ``` But, if none are provided, it will search for CSS files in the current directory and its subdirectories. ``` ≈ tailwindcss v4.0.0-alpha.24 │ No files provided. Searching for CSS files in the current │ directory and its subdirectories… │ Migration complete. Verify the changes and commit them to │ your repository. ``` The tooling also requires the Git repository to be in a clean state. This is a common convention to ensure that everything is undo-able. If we detect that the git repository is dirty, we will abort the migration. ``` ≈ tailwindcss v4.0.0-alpha.24 │ Git directory is not clean. Please stash or commit your │ changes before migrating. │ You may use the `--force` flag to override this safety │ check. ``` --- This PR alsoo adds CSS codemods for migrating existing `@apply` directives to the new version. This PR has the ability to migrate the following cases: --- In v4, the convention is to put the important modifier `!` at the end of the utility class instead of right before it. This makes it easier to reason about, especially when you are variants. Input: ```css .foo { @apply !flex flex-col! hover:!items-start items-center; } ``` Output: ```css .foo { @apply flex! flex-col! hover:items-start! items-center; } ``` --- In v4 we don't support `!important` as a marker at the end of `@apply` directives. Instead, you can append the `!` to each utility class to make it `!important`. Input: ```css .foo { @apply flex flex-col !important; } ``` Output: ```css .foo { @apply flex! flex-col!; } ```
2024-09-18 16:45:43 +02:00
"description": "A utility-first CSS framework for rapidly building custom user interfaces.",
"license": "MIT",
"repository": {
"type": "git",
"url": "https://github.com/tailwindlabs/tailwindcss.git",
"directory": "packages/@tailwindcss-cli"
},
"bugs": "https://github.com/tailwindlabs/tailwindcss/issues",
"homepage": "https://tailwindcss.com",
"scripts": {
"lint": "tsc --noEmit",
"build": "tsup-node",
"dev": "pnpm run build -- --watch"
},
"bin": "./dist/index.mjs",
"exports": {
"./package.json": "./package.json"
},
"files": [
"dist"
],
"publishConfig": {
"provenance": true,
"access": "public"
},
"dependencies": {
Pin exact versions of `tailwindcss` and `@tailwindcss/*` (#16623) 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 ```
2025-02-18 11:44:12 +01:00
"@tailwindcss/node": "workspace:*",
"@tailwindcss/oxide": "workspace:*",
Bump dependencies (#20095) This PR bumps some of our dependencies, common dependencies were moved to pnpm's `catalog` feature. Closes #20092 Closes #20085 Closes #20075 Closes #20066 Closes #20062 ## Test plan - All tests still pass - Each dependency was published some time ago. Webpack has an even newer version that was published <15min ago. Will update that one later. [ci-all]
2026-05-21 17:58:55 +02:00
"dedent": "catalog:",
"enhanced-resolve": "catalog:",
Bump dependencies (#19957) This PR bumps dependencies in all the packages, typically just bumping to the latest patch release. Closes: #19936 Closes: #19917 Closes: #19899 Closes: #19897 Closes: #19845 Closes: #19832 Closes: #19967 Closes: #19968 ## Test plan 1. All tests still pass 2. All integration tests still pass [ci-all] to verify Linux, Windows and macOS
2026-04-24 21:21:12 +02:00
"globby": "^16.2.0",
Update jiti 2.6.1 → 2.7.0 (minor) (#20044) 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.6.1 → 2.7.0) · [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.7.0">2.7.0</a></h4> <blockquote><p dir="auto"><a href="https://bounce.depfu.com/github.com/unjs/jiti/compare/v2.6.1...v2.7.0">compare changes</a></p> <h3 dir="auto">🚀 Enhancements</h3> <ul dir="auto"> <li>Add explicit resource management (<code class="notranslate">using</code>/<code class="notranslate">await using</code>) support (<a href="https://bounce.depfu.com/github.com/unjs/jiti/pull/422">#422</a>)</li> <li>Support opt-in <code class="notranslate">tsconfigPaths</code> (<a href="https://bounce.depfu.com/github.com/unjs/jiti/pull/427">#427</a>)</li> <li>Support virtual modules (<a href="https://bounce.depfu.com/github.com/unjs/jiti/pull/428">#428</a>)</li> <li>Add <code class="notranslate">jiti/static</code> subpath (<a href="https://bounce.depfu.com/github.com/unjs/jiti/pull/430">#430</a>)</li> </ul> <h3 dir="auto">🔥 Performance</h3> <ul dir="auto"> <li> <strong>interopDefault:</strong> Add caching to reduce proxy overhead by ~2x (<a href="https://bounce.depfu.com/github.com/unjs/jiti/pull/421">#421</a>)</li> </ul> <h3 dir="auto">🩹 Fixes</h3> <ul dir="auto"> <li> <strong>require:</strong> Passthrough resolve options (<a href="https://bounce.depfu.com/github.com/unjs/jiti/pull/412">#412</a>)</li> <li> <strong>require:</strong> Fallback to transpilation when <code class="notranslate">tryNative</code> fails (<a href="https://bounce.depfu.com/github.com/unjs/jiti/pull/413">#413</a>)</li> <li>Fallback for <code class="notranslate">ENAMETOOLONG</code> when evaluating esm (<a href="https://bounce.depfu.com/github.com/unjs/jiti/pull/429">#429</a>)</li> </ul> <h3 dir="auto">📦 Build</h3> <ul dir="auto"> <li>Upgrade rspack to v2 (<a href="https://bounce.depfu.com/github.com/unjs/jiti/commit/55194fb">55194fb</a>)</li> <li>Experimental rolldown config (<a href="https://bounce.depfu.com/github.com/unjs/jiti/commit/8c0243f">8c0243f</a>)</li> </ul> <h3 dir="auto">✅ Tests</h3> <ul dir="auto"> <li>Ignore jsx test for bun/cjs (<a href="https://bounce.depfu.com/github.com/unjs/jiti/commit/3a744ca">3a744ca</a>)</li> </ul> <h3 dir="auto">❤️ Contributors</h3> <ul dir="auto"> <li>Pooya Parsa (<a href="https://bounce.depfu.com/github.com/pi0">@pi0</a>)</li> <li>Kricsleo (<a href="https://bounce.depfu.com/github.com/kricsleo">@kricsleo</a>)</li> <li>Espen Hovlandsdal (<a href="https://bounce.depfu.com/github.com/rexxars">@rexxars</a>)</li> <li>Rintaro Itokawa (<a href="https://bounce.depfu.com/github.com/re-taro">@re-taro</a>)</li> <li>Matteo Collina (<a href="https://bounce.depfu.com/github.com/mcollina">@mcollina</a>)</li> <li>Mario Zechner (<a href="https://bounce.depfu.com/github.com/badlogic">@badlogic</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="https://github.com/unjs/jiti/compare/aedcdee7fed09dfd1cb7945daff64a6e41004f09...fd3bb289b75ed207edfb686d671ed50144f7e90f">See the full diff on Github</a>. The new version differs by 29 commits:</p> <ul> <li><a href="https://github.com/unjs/jiti/commit/fd3bb289b75ed207edfb686d671ed50144f7e90f"><code>chore(release): v2.7.0</code></a></li> <li><a href="https://github.com/unjs/jiti/commit/27fe3f2a496b712674061c767f21ceaf34d39d83"><code>chore: update release script</code></a></li> <li><a href="https://github.com/unjs/jiti/commit/4fcd2f23aa31d2e1ece4b307350b8c1d72a26870"><code>fix: fallback for `ENAMETOOLONG` when evaluating esm (#429)</code></a></li> <li><a href="https://github.com/unjs/jiti/commit/8c0243f14e65193fceb023b81aed5c9a820ee2cb"><code>build: experimental rolldown config</code></a></li> <li><a href="https://github.com/unjs/jiti/commit/55194fbb97b56af50ae1c19735ee3b06110b3903"><code>build: upgrade rspack</code></a></li> <li><a href="https://github.com/unjs/jiti/commit/0abda72c11fa31654ae17f255f9a854e4b706018"><code>ci: update node test matrix</code></a></li> <li><a href="https://github.com/unjs/jiti/commit/8c7822ef2ff03669c31de2fedfcf6676970f5b2a"><code>chore: update tsconfig</code></a></li> <li><a href="https://github.com/unjs/jiti/commit/08fc868c928d65fb615800e51b0ec1ac78f83a69"><code>chore: update deps</code></a></li> <li><a href="https://github.com/unjs/jiti/commit/5d552e3bebf9ffcd3fb9f176364fce7b4e35134d"><code>feat: add `jiti/static` export (#430)</code></a></li> <li><a href="https://github.com/unjs/jiti/commit/ae790b0214512857e40e8b3078b63a7d65f7f2c9"><code>feat: support virtual modules option (#428)</code></a></li> <li><a href="https://github.com/unjs/jiti/commit/a3e705dbdcda999c85a481448b9fa471bb88661b"><code>fix(require): fallback to transpilation when `tryNative` fails (#413)</code></a></li> <li><a href="https://github.com/unjs/jiti/commit/4deba1628391ca636f698515457f4f59619d637e"><code>chore: update agents.md</code></a></li> <li><a href="https://github.com/unjs/jiti/commit/f85b0e523d4f5f82f08c90765b63a077abd7bebe"><code>lint</code></a></li> <li><a href="https://github.com/unjs/jiti/commit/3ce242653f50f0987ffc596706c264b755daf527"><code>feat: support opt-in `tsconfigPaths` (#427)</code></a></li> <li><a href="https://github.com/unjs/jiti/commit/c49c54e42e0863fffe25164b50983aebe635a4d2"><code>chore: init agents.md</code></a></li> <li><a href="https://github.com/unjs/jiti/commit/b66bd233c21644c12a2341022a68b2263d2f1ed9"><code>feat: add explicit resource management (using/await using) support (#422)</code></a></li> <li><a href="https://github.com/unjs/jiti/commit/a467d31ffccd833947c18e925007c5bba910e0d6"><code>perf(interopDefault): add caching to reduce proxy overhead by ~2x (#421)</code></a></li> <li><a href="https://github.com/unjs/jiti/commit/fe264b49f1d89a8a8f30facc82fc182210f52186"><code>fix(ci): skip `--coverage` flag for node 18</code></a></li> <li><a href="https://github.com/unjs/jiti/commit/058d91a338fb3062064db745c9b2cc2335773138"><code>chore: lint</code></a></li> <li><a href="https://github.com/unjs/jiti/commit/650bc48a760e7aabefdbad79ad6a9f79f23578df"><code>chore: add missing prettier dep</code></a></li> <li><a href="https://github.com/unjs/jiti/commit/e28b5e9645b0502dd88dfb17e9a422740faa59e1"><code>chore(deps): update autofix-ci/action digest to 7a166d7 (#424)</code></a></li> <li><a href="https://github.com/unjs/jiti/commit/31096aa9e2d689a0b33e26a24304a9f5e8e38da9"><code>chore(deps): update actions/checkout action to v6 (#419)</code></a></li> <li><a href="https://github.com/unjs/jiti/commit/498e8d73a46e1624285662a9c43e1f05a534a34a"><code>chore: update deps</code></a></li> <li><a href="https://github.com/unjs/jiti/commit/9ee314fd0f5cb68d3c9db2987c5ffd91e250b93f"><code>test: update</code></a></li> <li><a href="https://github.com/unjs/jiti/commit/3a744ca27125e1332179692b0ef14b9da4097a4e"><code>test: ignore jsx test for bun/cjs</code></a></li> <li><a href="https://github.com/unjs/jiti/commit/e88ac44079e3839791c01f12342be385c87ba993"><code>chore: update deps</code></a></li> <li><a href="https://github.com/unjs/jiti/commit/4045c7a2a2fc49566124f32e1c4597f995f1e22f"><code>chore: fix lint issues</code></a></li> <li><a href="https://github.com/unjs/jiti/commit/39e86de57c1c866ff4568c17eb625afb325fbdec"><code>chore(deps): update actions/setup-node action to v6 (#411)</code></a></li> <li><a href="https://github.com/unjs/jiti/commit/ddb4683d374ec18e396ab42f180ca21c7147b17b"><code>fix(require): passthrough resolve options (#412)</code></a></li> </ul> </details> --- ![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>
2026-05-13 12:02:13 +02:00
"jiti": "^2.7.0",
Add initial codemod tooling (#14434) This PR adds some initial tooling for codemods. We are currently only interested in migrating CSS files, so we will be using PostCSS under the hood to do this. This PR also implements the "migrate `@apply`" codemod from #14412. The usage will look like this: ```sh npx @tailwindcss/upgrade ``` You can pass in CSS files to transform as arguments: ```sh npx @tailwindcss/upgrade src/**/*.css ``` But, if none are provided, it will search for CSS files in the current directory and its subdirectories. ``` ≈ tailwindcss v4.0.0-alpha.24 │ No files provided. Searching for CSS files in the current │ directory and its subdirectories… │ Migration complete. Verify the changes and commit them to │ your repository. ``` The tooling also requires the Git repository to be in a clean state. This is a common convention to ensure that everything is undo-able. If we detect that the git repository is dirty, we will abort the migration. ``` ≈ tailwindcss v4.0.0-alpha.24 │ Git directory is not clean. Please stash or commit your │ changes before migrating. │ You may use the `--force` flag to override this safety │ check. ``` --- This PR alsoo adds CSS codemods for migrating existing `@apply` directives to the new version. This PR has the ability to migrate the following cases: --- In v4, the convention is to put the important modifier `!` at the end of the utility class instead of right before it. This makes it easier to reason about, especially when you are variants. Input: ```css .foo { @apply !flex flex-col! hover:!items-start items-center; } ``` Output: ```css .foo { @apply flex! flex-col! hover:items-start! items-center; } ``` --- In v4 we don't support `!important` as a marker at the end of `@apply` directives. Instead, you can append the `!` to each utility class to make it `!important`. Input: ```css .foo { @apply flex flex-col !important; } ``` Output: ```css .foo { @apply flex! flex-col!; } ```
2024-09-18 16:45:43 +02:00
"mri": "^1.2.0",
Update picocolors 1.0.1 → 1.1.1 (minor) (#14771)
2024-10-24 11:25:50 +02:00
"picocolors": "^1.1.1",
Bump dependencies (#20095) This PR bumps some of our dependencies, common dependencies were moved to pnpm's `catalog` feature. Closes #20092 Closes #20085 Closes #20075 Closes #20066 Closes #20062 ## Test plan - All tests still pass - Each dependency was published some time ago. Webpack has an even newer version that was published <15min ago. Will update that one later. [ci-all]
2026-05-21 17:58:55 +02:00
"postcss": "catalog:",
Update postcss-import 16.1.0 → 16.1.1 (patch) (#18376) 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? #### ✳️ postcss-import (16.1.0 → 16.1.1) · [Repo](https://github.com/postcss/postcss-import) · [Changelog](https://github.com/postcss/postcss-import/blob/master/CHANGELOG.md) <details> <summary>Release Notes</summary> <h4>16.1.1 (from changelog)</h4> <blockquote><ul dir="auto"> <li>Fix incorrect cascade layer order when some resources can not be inlined (<a href="https://bounce.depfu.com/github.com/postcss/postcss-import/issues/567">#567</a>, <a href="https://bounce.depfu.com/github.com/postcss/postcss-import/pull/574">#574</a>)</li> </ul></blockquote> <p><em>Does any of this look wrong? <a href="https://depfu.com/packages/npm/postcss-import/feedback">Please let us know.</a></em></p> </details> <details> <summary>Commits</summary> <p><a href="https://github.com/postcss/postcss-import/compare/9217ec361b8d0b062841d5634f40017aeaad078b...4ae9894edc6bced4ad983c5556de493d77c8cc6d">See the full diff on Github</a>. The new version differs by 10 commits:</p> <ul> <li><a href="https://github.com/postcss/postcss-import/commit/4ae9894edc6bced4ad983c5556de493d77c8cc6d"><code>16.1.1</code></a></li> <li><a href="https://github.com/postcss/postcss-import/commit/a3f38897da54e61bcb4a34484dc6a6c0543134bc"><code>Test on modern Node versions (#577)</code></a></li> <li><a href="https://github.com/postcss/postcss-import/commit/10325fc02498da689d3c6f2821c6448c6064831c"><code>Upgrade eslint &amp; config; use flat config (#576)</code></a></li> <li><a href="https://github.com/postcss/postcss-import/commit/92276420402a400566f30d7b494f8b51ef76b0f1"><code>Migrate config renovate.json (#575)</code></a></li> <li><a href="https://github.com/postcss/postcss-import/commit/25441554913ca9f4f8469636ef7001d9cdbdb832"><code>Update dependency prettier to ~3.5.0 (#572)</code></a></li> <li><a href="https://github.com/postcss/postcss-import/commit/83108aa207e96eeac159dde08e2153cddeb7172e"><code>Fix incorrect cascade layer order when some resources can not be inlined (#574)</code></a></li> <li><a href="https://github.com/postcss/postcss-import/commit/cad00220bf02f881be6475e943c499906b623241"><code>Update dependency sugarss to v5 (#568)</code></a></li> <li><a href="https://github.com/postcss/postcss-import/commit/32deb082c687c0d324e5812b3593f7e44af10166"><code>Update dependency c8 to v10 (#565)</code></a></li> <li><a href="https://github.com/postcss/postcss-import/commit/d43ca1506d65d9943a3c4bb885aff94dc809d69c"><code>Update dependency prettier to ~3.4.0 (#569)</code></a></li> <li><a href="https://github.com/postcss/postcss-import/commit/9af465e598b51f933ac15baeab09caf086c3083b"><code>Update dependency prettier to ~3.3.0 (#564)</code></a></li> </ul> </details> --- ![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>
2025-06-24 09:57:35 -04:00
"postcss-import": "^16.1.1",
Update all pnpm dependencies (2026-06-19) (#20262) This is your weekly update of **all** pnpm dependencies. Please take a good look at what changed and the test results before merging this pull request. ### What changed? ✳️ postcss-selector-parser (7.1.1 → 7.1.4, patch) · [Repo](https://github.com/postcss/postcss-selector-parser) · [Changelog](https://github.com/postcss/postcss-selector-parser/blob/master/CHANGELOG.md) · [Release](https://github.com/postcss/postcss-selector-parser/releases/tag/7.1.4) · [Diff](https://github.com/postcss/postcss-selector-parser/compare/cf6637ed6a2dbc9d24bc3a1d04ec7ac4629dd856...4a7e4e3685db8ab8e52e51ecdbe8162a8568f70c) ✳️ semver (7.8.1 → 7.8.4, patch) · [Repo](https://github.com/npm/node-semver) · [Changelog](https://github.com/npm/node-semver/blob/main/CHANGELOG.md) · [Release](https://github.com/npm/node-semver/releases/tag/v7.8.4) · [Diff](https://github.com/npm/node-semver/compare/76416081a8413383cf6e24c82cafa438bd076d41...8640bd68f1653e504b53e9be4030eccdfe4c307a) ✳️ turbo (2.9.14 → 2.9.18, patch) · [Repo](https://github.com/vercel/turborepo) · [Changelog](https://github.com/vercel/turborepo/blob/main/RELEASE.md) · [Release](https://github.com/vercel/turborepo/releases/tag/v2.9.18) · [Diff](https://github.com/vercel/turborepo/compare/fc62fe0d9c347d1d24f0ed8946284856593ddb93...3bdce3277d2e61cdbf29f244a515dd4b896d2556) --- ![Depfu Status](https://depfu.com/badges/edd6acd35d74c8d41cbb540c30442adf/stats.svg) [Depfu](https://depfu.com) will only send you the next scheduled PR once you merge or close this one. <details><summary>All Depfu comment commands</summary> <blockquote><dl> <dt>@​depfu refresh</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> </dl></blockquote> </details> Co-authored-by: depfu[bot] <23717796+depfu[bot]@users.noreply.github.com>
2026-06-19 13:11:16 +02:00
"postcss-selector-parser": "^7.1.4",
Bump and pin `prettier` (#16382) 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.
2025-02-10 10:54:45 +01:00
"prettier": "catalog:",
Update all pnpm dependencies (2026-06-19) (#20262) This is your weekly update of **all** pnpm dependencies. Please take a good look at what changed and the test results before merging this pull request. ### What changed? ✳️ postcss-selector-parser (7.1.1 → 7.1.4, patch) · [Repo](https://github.com/postcss/postcss-selector-parser) · [Changelog](https://github.com/postcss/postcss-selector-parser/blob/master/CHANGELOG.md) · [Release](https://github.com/postcss/postcss-selector-parser/releases/tag/7.1.4) · [Diff](https://github.com/postcss/postcss-selector-parser/compare/cf6637ed6a2dbc9d24bc3a1d04ec7ac4629dd856...4a7e4e3685db8ab8e52e51ecdbe8162a8568f70c) ✳️ semver (7.8.1 → 7.8.4, patch) · [Repo](https://github.com/npm/node-semver) · [Changelog](https://github.com/npm/node-semver/blob/main/CHANGELOG.md) · [Release](https://github.com/npm/node-semver/releases/tag/v7.8.4) · [Diff](https://github.com/npm/node-semver/compare/76416081a8413383cf6e24c82cafa438bd076d41...8640bd68f1653e504b53e9be4030eccdfe4c307a) ✳️ turbo (2.9.14 → 2.9.18, patch) · [Repo](https://github.com/vercel/turborepo) · [Changelog](https://github.com/vercel/turborepo/blob/main/RELEASE.md) · [Release](https://github.com/vercel/turborepo/releases/tag/v2.9.18) · [Diff](https://github.com/vercel/turborepo/compare/fc62fe0d9c347d1d24f0ed8946284856593ddb93...3bdce3277d2e61cdbf29f244a515dd4b896d2556) --- ![Depfu Status](https://depfu.com/badges/edd6acd35d74c8d41cbb540c30442adf/stats.svg) [Depfu](https://depfu.com) will only send you the next scheduled PR once you merge or close this one. <details><summary>All Depfu comment commands</summary> <blockquote><dl> <dt>@​depfu refresh</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> </dl></blockquote> </details> Co-authored-by: depfu[bot] <23717796+depfu[bot]@users.noreply.github.com>
2026-06-19 13:11:16 +02:00
"semver": "^7.8.4",
Ensure `@tailwindcss/upgrade` runs on Tailwind CSS v4 projects and is idempotent (#17717) This PR ensures that the `@tailwindcss/upgrade` tool works on existing Tailwind CSS v4 projects. This PR also ensures that the upgrade tool is idempotent, meaning that it can be run multiple times and it should result in the same output. One awesome feature this unlocks is that you can run the upgrade tool on your codebase at any time and upgrade classes if you still have some legacy syntaxes, such as `bg-[var(--my-color)]`, in your muscle memory. One small note: If something changed in the first run, re-running will not work immediately because your git repository will not be clean and the upgrade tool requires your git repo to be clean. But once you verified and committed your changes, the upgrade tool will be idempotent. Idempotency is guaranteed by ensuring that some migrations are skipped by checking what version of Tailwind CSS you are on _before_ the version is upgraded. For the Tailwind CSS version: We will resolve `tailwindcss` itself to know the _actual_ version that is installed (the one resolved from `node_modules`). Not the one available in your package.json. Your `package.json` could be out of sync if you reverted changes but didn't run `npm install` yet. Back to Idempotency: For example, we have migrations where we change the variant order of stacked variants. If we would run these migrations every time you run the upgrade tool then we would be flip-flopping the order every run. See: https://tailwindcss.com/docs/upgrade-guide#variant-stacking-order Another example is where we rename some utilities. For example, we rename: | Before | After | | ----------- | ----------- | | `shadow` | `shadow-sm` | | `shadow-sm` | `shadow-xs` | Notice how we have `shadow-sm` in both the `before` and `after` column. If we would run the upgrade tool again, then we would eventually migrate your original `shadow` to `shadow-sm` (first run) and then to `shadow-xs` (second run). Which would result in the wrong shadow. See: https://tailwindcss.com/docs/upgrade-guide#renamed-utilities --- The order of upgrade steps changed a bit as well to make the internals are easier to work with and reason about. 1. Find CSS files 2. Link JS config files (if you are in a Tailwind CSS v3 project) 3. Migrate the JS config files (if you are in a Tailwind CSS v3 project) 4. Upgrade Tailwind CSS to v4 (or the latest version at that point) 5. Migrate the stylesheets (we used to migrate the source files first) 6. Migrate the source files This is done so that step 5 and 6 will always operate on a Tailwind CSS v4 project and we don't need to check the version number again. This is also necessary because your CSS file will now very likely contain `@import "tailwindcss";` which doesn't exist in Tailwind CSS v3. This also means that we can rely on the same internals that Tailwind CSS actually uses for locating the source files. We will use `@tailwindcss/oxide`'s scanner to find the source files (and it also keeps your custom `@source` directives into account). This PR also introduces a few actual migrations related to recent features and changes we shipped. 1. We migrate deprecated classes to their new names: | Before | After | | --------------------- | --------------------- | | `bg-left-top` | `bg-top-left` | | `bg-left-bottom` | `bg-bottom-left` | | `bg-right-top` | `bg-top-right` | | `bg-right-bottom` | `bg-bottom-right` | | `object-left-top` | `object-top-left` | | `object-left-bottom` | `object-bottom-left` | | `object-right-top` | `object-top-right` | | `object-right-bottom` | `object-bottom-right` | Introduced in: - https://github.com/tailwindlabs/tailwindcss/pull/17378 - https://github.com/tailwindlabs/tailwindcss/pull/17437 2. We migrate simple arbitrary variants to their dedicated variant: | Before | After | | ----------------------- | ------------------- | | `[&:user-valid]:flex` | `user-valid:flex` | | `[&:user-invalid]:flex` | `user-invalid:flex` | Introduced in: - https://github.com/tailwindlabs/tailwindcss/pull/12370 3. We migrate `@media` variants to their dedicated variant: | Before | After | | ----------------------------------------------------- | ------------------------- | | `[@media_print]:flex` | `print:flex` | | `[@media(prefers-reduced-motion:no-preference)]:flex` | `motion-safe:flex` | | `[@media(prefers-reduced-motion:reduce)]:flex` | `motion-reduce:flex` | | `[@media(prefers-contrast:more)]:flex` | `contrast-more:flex` | | `[@media(prefers-contrast:less)]:flex` | `contrast-less:flex` | | `[@media(orientation:portrait)]:flex` | `portrait:flex` | | `[@media(orientation:landscape)]:flex` | `landscape:flex` | | `[@media(forced-colors:active)]:flex` | `forced-colors:flex` | | `[@media(inverted-colors:inverted)]:flex` | `inverted-colors:flex` | | `[@media(pointer:none)]:flex` | `pointer-none:flex` | | `[@media(pointer:coarse)]:flex` | `pointer-coarse:flex` | | `[@media(pointer:fine)]:flex` | `pointer-fine:flex` | | `[@media(any-pointer:none)]:flex` | `any-pointer-none:flex` | | `[@media(any-pointer:coarse)]:flex` | `any-pointer-coarse:flex` | | `[@media(any-pointer:fine)]:flex` | `any-pointer-fine:flex` | | `[@media(scripting:none)]:flex` | `noscript:flex` | The new variants related to `inverted-colors`, `pointer`, `any-pointer` and `scripting` were introduced in: - https://github.com/tailwindlabs/tailwindcss/pull/11693 - https://github.com/tailwindlabs/tailwindcss/pull/16946 - https://github.com/tailwindlabs/tailwindcss/pull/11929 - https://github.com/tailwindlabs/tailwindcss/pull/17431 This also applies to the `not` case, e.g.: | Before | After | | --------------------------------------------------------- | ----------------------------- | | `[@media_not_print]:flex` | `not-print:flex` | | `[@media_not(prefers-reduced-motion:no-preference)]:flex` | `not-motion-safe:flex` | | `[@media_not(prefers-reduced-motion:reduce)]:flex` | `not-motion-reduce:flex` | | `[@media_not(prefers-contrast:more)]:flex` | `not-contrast-more:flex` | | `[@media_not(prefers-contrast:less)]:flex` | `not-contrast-less:flex` | | `[@media_not(orientation:portrait)]:flex` | `not-portrait:flex` | | `[@media_not(orientation:landscape)]:flex` | `not-landscape:flex` | | `[@media_not(forced-colors:active)]:flex` | `not-forced-colors:flex` | | `[@media_not(inverted-colors:inverted)]:flex` | `not-inverted-colors:flex` | | `[@media_not(pointer:none)]:flex` | `not-pointer-none:flex` | | `[@media_not(pointer:coarse)]:flex` | `not-pointer-coarse:flex` | | `[@media_not(pointer:fine)]:flex` | `not-pointer-fine:flex` | | `[@media_not(any-pointer:none)]:flex` | `not-any-pointer-none:flex` | | `[@media_not(any-pointer:coarse)]:flex` | `not-any-pointer-coarse:flex` | | `[@media_not(any-pointer:fine)]:flex` | `not-any-pointer-fine:flex` | | `[@media_not(scripting:none)]:flex` | `not-noscript:flex` | For each candidate, we run a set of upgrade migrations. If at the end of the migrations the original candidate is still the same as the new candidate, then we will parse & print the candidate one more time to pretty print into consistent classes. Luckily parsing is cached so there is no real downside overhead. Consistency (especially with arbitrary variants and values) will reduce your CSS file because there will be fewer "versions" of your class. Concretely, the pretty printing will apply changes such as: | Before | After | | ---------------------- | ----------------- | | `bg-[var(--my-color)]` | `bg-(--my-color)` | | `bg-[rgb(0,_0,_0)]` | `bg-[rgb(0,0,0)]` | Another big important reason for this change is that these classes on their own would have been migrated _if_ another migration was relevant for this candidate. This means that there are were some inconsistencies. E.g.: | Before | After | Reason | | ----------------------- | ---------------------- | ------------------------------------ | | `!bg-[var(--my-color)]` | `bg-(--my-color)!` | Because the `!` is in the wrong spot | | `bg-[var(--my-color)]` | `bg-[var(--my-color)]` | Because no migrations rand | As you can see, the way the `--my-color` variable is used, is different. This changes will make sure it will now always be consistent: | Before | After | | ----------------------- | ---------------------- | | `!bg-[var(--my-color)]` | `bg-(--my-color)!` | | `bg-[var(--my-color)]` | `bg-(--my-color)` | Yay! Of course, if you don't want these more cosmetic changes, you can always ignore the upgrade and revert these changes and only commit the changes you want. # Test plan - All existing tests still pass. - But I had to delete 1 test (we tested that Tailwind CSS v3 was required). - And had to mock the `version.isMajor` call to ensure we run the individual migration tests correctly. - Added new tests to test: 1. Migrating Tailwind CSS v4 projects works 1. Idempotency of the upgrade tool [ci-all]
2025-04-22 17:10:46 +02:00
"tailwindcss": "workspace:*",
Update tree-sitter 0.22.1 → 0.22.4 (minor) (#15585)
2025-01-10 10:26:48 +01:00
"tree-sitter": "^0.22.4",
Ensure `@tailwindcss/upgrade` runs on Tailwind CSS v4 projects and is idempotent (#17717) This PR ensures that the `@tailwindcss/upgrade` tool works on existing Tailwind CSS v4 projects. This PR also ensures that the upgrade tool is idempotent, meaning that it can be run multiple times and it should result in the same output. One awesome feature this unlocks is that you can run the upgrade tool on your codebase at any time and upgrade classes if you still have some legacy syntaxes, such as `bg-[var(--my-color)]`, in your muscle memory. One small note: If something changed in the first run, re-running will not work immediately because your git repository will not be clean and the upgrade tool requires your git repo to be clean. But once you verified and committed your changes, the upgrade tool will be idempotent. Idempotency is guaranteed by ensuring that some migrations are skipped by checking what version of Tailwind CSS you are on _before_ the version is upgraded. For the Tailwind CSS version: We will resolve `tailwindcss` itself to know the _actual_ version that is installed (the one resolved from `node_modules`). Not the one available in your package.json. Your `package.json` could be out of sync if you reverted changes but didn't run `npm install` yet. Back to Idempotency: For example, we have migrations where we change the variant order of stacked variants. If we would run these migrations every time you run the upgrade tool then we would be flip-flopping the order every run. See: https://tailwindcss.com/docs/upgrade-guide#variant-stacking-order Another example is where we rename some utilities. For example, we rename: | Before | After | | ----------- | ----------- | | `shadow` | `shadow-sm` | | `shadow-sm` | `shadow-xs` | Notice how we have `shadow-sm` in both the `before` and `after` column. If we would run the upgrade tool again, then we would eventually migrate your original `shadow` to `shadow-sm` (first run) and then to `shadow-xs` (second run). Which would result in the wrong shadow. See: https://tailwindcss.com/docs/upgrade-guide#renamed-utilities --- The order of upgrade steps changed a bit as well to make the internals are easier to work with and reason about. 1. Find CSS files 2. Link JS config files (if you are in a Tailwind CSS v3 project) 3. Migrate the JS config files (if you are in a Tailwind CSS v3 project) 4. Upgrade Tailwind CSS to v4 (or the latest version at that point) 5. Migrate the stylesheets (we used to migrate the source files first) 6. Migrate the source files This is done so that step 5 and 6 will always operate on a Tailwind CSS v4 project and we don't need to check the version number again. This is also necessary because your CSS file will now very likely contain `@import "tailwindcss";` which doesn't exist in Tailwind CSS v3. This also means that we can rely on the same internals that Tailwind CSS actually uses for locating the source files. We will use `@tailwindcss/oxide`'s scanner to find the source files (and it also keeps your custom `@source` directives into account). This PR also introduces a few actual migrations related to recent features and changes we shipped. 1. We migrate deprecated classes to their new names: | Before | After | | --------------------- | --------------------- | | `bg-left-top` | `bg-top-left` | | `bg-left-bottom` | `bg-bottom-left` | | `bg-right-top` | `bg-top-right` | | `bg-right-bottom` | `bg-bottom-right` | | `object-left-top` | `object-top-left` | | `object-left-bottom` | `object-bottom-left` | | `object-right-top` | `object-top-right` | | `object-right-bottom` | `object-bottom-right` | Introduced in: - https://github.com/tailwindlabs/tailwindcss/pull/17378 - https://github.com/tailwindlabs/tailwindcss/pull/17437 2. We migrate simple arbitrary variants to their dedicated variant: | Before | After | | ----------------------- | ------------------- | | `[&:user-valid]:flex` | `user-valid:flex` | | `[&:user-invalid]:flex` | `user-invalid:flex` | Introduced in: - https://github.com/tailwindlabs/tailwindcss/pull/12370 3. We migrate `@media` variants to their dedicated variant: | Before | After | | ----------------------------------------------------- | ------------------------- | | `[@media_print]:flex` | `print:flex` | | `[@media(prefers-reduced-motion:no-preference)]:flex` | `motion-safe:flex` | | `[@media(prefers-reduced-motion:reduce)]:flex` | `motion-reduce:flex` | | `[@media(prefers-contrast:more)]:flex` | `contrast-more:flex` | | `[@media(prefers-contrast:less)]:flex` | `contrast-less:flex` | | `[@media(orientation:portrait)]:flex` | `portrait:flex` | | `[@media(orientation:landscape)]:flex` | `landscape:flex` | | `[@media(forced-colors:active)]:flex` | `forced-colors:flex` | | `[@media(inverted-colors:inverted)]:flex` | `inverted-colors:flex` | | `[@media(pointer:none)]:flex` | `pointer-none:flex` | | `[@media(pointer:coarse)]:flex` | `pointer-coarse:flex` | | `[@media(pointer:fine)]:flex` | `pointer-fine:flex` | | `[@media(any-pointer:none)]:flex` | `any-pointer-none:flex` | | `[@media(any-pointer:coarse)]:flex` | `any-pointer-coarse:flex` | | `[@media(any-pointer:fine)]:flex` | `any-pointer-fine:flex` | | `[@media(scripting:none)]:flex` | `noscript:flex` | The new variants related to `inverted-colors`, `pointer`, `any-pointer` and `scripting` were introduced in: - https://github.com/tailwindlabs/tailwindcss/pull/11693 - https://github.com/tailwindlabs/tailwindcss/pull/16946 - https://github.com/tailwindlabs/tailwindcss/pull/11929 - https://github.com/tailwindlabs/tailwindcss/pull/17431 This also applies to the `not` case, e.g.: | Before | After | | --------------------------------------------------------- | ----------------------------- | | `[@media_not_print]:flex` | `not-print:flex` | | `[@media_not(prefers-reduced-motion:no-preference)]:flex` | `not-motion-safe:flex` | | `[@media_not(prefers-reduced-motion:reduce)]:flex` | `not-motion-reduce:flex` | | `[@media_not(prefers-contrast:more)]:flex` | `not-contrast-more:flex` | | `[@media_not(prefers-contrast:less)]:flex` | `not-contrast-less:flex` | | `[@media_not(orientation:portrait)]:flex` | `not-portrait:flex` | | `[@media_not(orientation:landscape)]:flex` | `not-landscape:flex` | | `[@media_not(forced-colors:active)]:flex` | `not-forced-colors:flex` | | `[@media_not(inverted-colors:inverted)]:flex` | `not-inverted-colors:flex` | | `[@media_not(pointer:none)]:flex` | `not-pointer-none:flex` | | `[@media_not(pointer:coarse)]:flex` | `not-pointer-coarse:flex` | | `[@media_not(pointer:fine)]:flex` | `not-pointer-fine:flex` | | `[@media_not(any-pointer:none)]:flex` | `not-any-pointer-none:flex` | | `[@media_not(any-pointer:coarse)]:flex` | `not-any-pointer-coarse:flex` | | `[@media_not(any-pointer:fine)]:flex` | `not-any-pointer-fine:flex` | | `[@media_not(scripting:none)]:flex` | `not-noscript:flex` | For each candidate, we run a set of upgrade migrations. If at the end of the migrations the original candidate is still the same as the new candidate, then we will parse & print the candidate one more time to pretty print into consistent classes. Luckily parsing is cached so there is no real downside overhead. Consistency (especially with arbitrary variants and values) will reduce your CSS file because there will be fewer "versions" of your class. Concretely, the pretty printing will apply changes such as: | Before | After | | ---------------------- | ----------------- | | `bg-[var(--my-color)]` | `bg-(--my-color)` | | `bg-[rgb(0,_0,_0)]` | `bg-[rgb(0,0,0)]` | Another big important reason for this change is that these classes on their own would have been migrated _if_ another migration was relevant for this candidate. This means that there are were some inconsistencies. E.g.: | Before | After | Reason | | ----------------------- | ---------------------- | ------------------------------------ | | `!bg-[var(--my-color)]` | `bg-(--my-color)!` | Because the `!` is in the wrong spot | | `bg-[var(--my-color)]` | `bg-[var(--my-color)]` | Because no migrations rand | As you can see, the way the `--my-color` variable is used, is different. This changes will make sure it will now always be consistent: | Before | After | | ----------------------- | ---------------------- | | `!bg-[var(--my-color)]` | `bg-(--my-color)!` | | `bg-[var(--my-color)]` | `bg-(--my-color)` | Yay! Of course, if you don't want these more cosmetic changes, you can always ignore the upgrade and revert these changes and only commit the changes you want. # Test plan - All existing tests still pass. - But I had to delete 1 test (we tested that Tailwind CSS v3 was required). - And had to mock the `version.isMajor` call to ensure we run the individual migration tests correctly. - Added new tests to test: 1. Migrating Tailwind CSS v4 projects works 1. Idempotency of the upgrade tool [ci-all]
2025-04-22 17:10:46 +02:00
"tree-sitter-typescript": "^0.23.2"
Add initial codemod tooling (#14434) This PR adds some initial tooling for codemods. We are currently only interested in migrating CSS files, so we will be using PostCSS under the hood to do this. This PR also implements the "migrate `@apply`" codemod from #14412. The usage will look like this: ```sh npx @tailwindcss/upgrade ``` You can pass in CSS files to transform as arguments: ```sh npx @tailwindcss/upgrade src/**/*.css ``` But, if none are provided, it will search for CSS files in the current directory and its subdirectories. ``` ≈ tailwindcss v4.0.0-alpha.24 │ No files provided. Searching for CSS files in the current │ directory and its subdirectories… │ Migration complete. Verify the changes and commit them to │ your repository. ``` The tooling also requires the Git repository to be in a clean state. This is a common convention to ensure that everything is undo-able. If we detect that the git repository is dirty, we will abort the migration. ``` ≈ tailwindcss v4.0.0-alpha.24 │ Git directory is not clean. Please stash or commit your │ changes before migrating. │ You may use the `--force` flag to override this safety │ check. ``` --- This PR alsoo adds CSS codemods for migrating existing `@apply` directives to the new version. This PR has the ability to migrate the following cases: --- In v4, the convention is to put the important modifier `!` at the end of the utility class instead of right before it. This makes it easier to reason about, especially when you are variants. Input: ```css .foo { @apply !flex flex-col! hover:!items-start items-center; } ``` Output: ```css .foo { @apply flex! flex-col! hover:items-start! items-center; } ``` --- In v4 we don't support `!important` as a marker at the end of `@apply` directives. Instead, you can append the `!` to each utility class to make it `!important`. Input: ```css .foo { @apply flex flex-col !important; } ``` Output: ```css .foo { @apply flex! flex-col!; } ```
2024-09-18 16:45:43 +02:00
},
"devDependencies": {
"@types/node": "catalog:",
Ensure `@tailwindcss/upgrade` runs on Tailwind CSS v4 projects and is idempotent (#17717) This PR ensures that the `@tailwindcss/upgrade` tool works on existing Tailwind CSS v4 projects. This PR also ensures that the upgrade tool is idempotent, meaning that it can be run multiple times and it should result in the same output. One awesome feature this unlocks is that you can run the upgrade tool on your codebase at any time and upgrade classes if you still have some legacy syntaxes, such as `bg-[var(--my-color)]`, in your muscle memory. One small note: If something changed in the first run, re-running will not work immediately because your git repository will not be clean and the upgrade tool requires your git repo to be clean. But once you verified and committed your changes, the upgrade tool will be idempotent. Idempotency is guaranteed by ensuring that some migrations are skipped by checking what version of Tailwind CSS you are on _before_ the version is upgraded. For the Tailwind CSS version: We will resolve `tailwindcss` itself to know the _actual_ version that is installed (the one resolved from `node_modules`). Not the one available in your package.json. Your `package.json` could be out of sync if you reverted changes but didn't run `npm install` yet. Back to Idempotency: For example, we have migrations where we change the variant order of stacked variants. If we would run these migrations every time you run the upgrade tool then we would be flip-flopping the order every run. See: https://tailwindcss.com/docs/upgrade-guide#variant-stacking-order Another example is where we rename some utilities. For example, we rename: | Before | After | | ----------- | ----------- | | `shadow` | `shadow-sm` | | `shadow-sm` | `shadow-xs` | Notice how we have `shadow-sm` in both the `before` and `after` column. If we would run the upgrade tool again, then we would eventually migrate your original `shadow` to `shadow-sm` (first run) and then to `shadow-xs` (second run). Which would result in the wrong shadow. See: https://tailwindcss.com/docs/upgrade-guide#renamed-utilities --- The order of upgrade steps changed a bit as well to make the internals are easier to work with and reason about. 1. Find CSS files 2. Link JS config files (if you are in a Tailwind CSS v3 project) 3. Migrate the JS config files (if you are in a Tailwind CSS v3 project) 4. Upgrade Tailwind CSS to v4 (or the latest version at that point) 5. Migrate the stylesheets (we used to migrate the source files first) 6. Migrate the source files This is done so that step 5 and 6 will always operate on a Tailwind CSS v4 project and we don't need to check the version number again. This is also necessary because your CSS file will now very likely contain `@import "tailwindcss";` which doesn't exist in Tailwind CSS v3. This also means that we can rely on the same internals that Tailwind CSS actually uses for locating the source files. We will use `@tailwindcss/oxide`'s scanner to find the source files (and it also keeps your custom `@source` directives into account). This PR also introduces a few actual migrations related to recent features and changes we shipped. 1. We migrate deprecated classes to their new names: | Before | After | | --------------------- | --------------------- | | `bg-left-top` | `bg-top-left` | | `bg-left-bottom` | `bg-bottom-left` | | `bg-right-top` | `bg-top-right` | | `bg-right-bottom` | `bg-bottom-right` | | `object-left-top` | `object-top-left` | | `object-left-bottom` | `object-bottom-left` | | `object-right-top` | `object-top-right` | | `object-right-bottom` | `object-bottom-right` | Introduced in: - https://github.com/tailwindlabs/tailwindcss/pull/17378 - https://github.com/tailwindlabs/tailwindcss/pull/17437 2. We migrate simple arbitrary variants to their dedicated variant: | Before | After | | ----------------------- | ------------------- | | `[&:user-valid]:flex` | `user-valid:flex` | | `[&:user-invalid]:flex` | `user-invalid:flex` | Introduced in: - https://github.com/tailwindlabs/tailwindcss/pull/12370 3. We migrate `@media` variants to their dedicated variant: | Before | After | | ----------------------------------------------------- | ------------------------- | | `[@media_print]:flex` | `print:flex` | | `[@media(prefers-reduced-motion:no-preference)]:flex` | `motion-safe:flex` | | `[@media(prefers-reduced-motion:reduce)]:flex` | `motion-reduce:flex` | | `[@media(prefers-contrast:more)]:flex` | `contrast-more:flex` | | `[@media(prefers-contrast:less)]:flex` | `contrast-less:flex` | | `[@media(orientation:portrait)]:flex` | `portrait:flex` | | `[@media(orientation:landscape)]:flex` | `landscape:flex` | | `[@media(forced-colors:active)]:flex` | `forced-colors:flex` | | `[@media(inverted-colors:inverted)]:flex` | `inverted-colors:flex` | | `[@media(pointer:none)]:flex` | `pointer-none:flex` | | `[@media(pointer:coarse)]:flex` | `pointer-coarse:flex` | | `[@media(pointer:fine)]:flex` | `pointer-fine:flex` | | `[@media(any-pointer:none)]:flex` | `any-pointer-none:flex` | | `[@media(any-pointer:coarse)]:flex` | `any-pointer-coarse:flex` | | `[@media(any-pointer:fine)]:flex` | `any-pointer-fine:flex` | | `[@media(scripting:none)]:flex` | `noscript:flex` | The new variants related to `inverted-colors`, `pointer`, `any-pointer` and `scripting` were introduced in: - https://github.com/tailwindlabs/tailwindcss/pull/11693 - https://github.com/tailwindlabs/tailwindcss/pull/16946 - https://github.com/tailwindlabs/tailwindcss/pull/11929 - https://github.com/tailwindlabs/tailwindcss/pull/17431 This also applies to the `not` case, e.g.: | Before | After | | --------------------------------------------------------- | ----------------------------- | | `[@media_not_print]:flex` | `not-print:flex` | | `[@media_not(prefers-reduced-motion:no-preference)]:flex` | `not-motion-safe:flex` | | `[@media_not(prefers-reduced-motion:reduce)]:flex` | `not-motion-reduce:flex` | | `[@media_not(prefers-contrast:more)]:flex` | `not-contrast-more:flex` | | `[@media_not(prefers-contrast:less)]:flex` | `not-contrast-less:flex` | | `[@media_not(orientation:portrait)]:flex` | `not-portrait:flex` | | `[@media_not(orientation:landscape)]:flex` | `not-landscape:flex` | | `[@media_not(forced-colors:active)]:flex` | `not-forced-colors:flex` | | `[@media_not(inverted-colors:inverted)]:flex` | `not-inverted-colors:flex` | | `[@media_not(pointer:none)]:flex` | `not-pointer-none:flex` | | `[@media_not(pointer:coarse)]:flex` | `not-pointer-coarse:flex` | | `[@media_not(pointer:fine)]:flex` | `not-pointer-fine:flex` | | `[@media_not(any-pointer:none)]:flex` | `not-any-pointer-none:flex` | | `[@media_not(any-pointer:coarse)]:flex` | `not-any-pointer-coarse:flex` | | `[@media_not(any-pointer:fine)]:flex` | `not-any-pointer-fine:flex` | | `[@media_not(scripting:none)]:flex` | `not-noscript:flex` | For each candidate, we run a set of upgrade migrations. If at the end of the migrations the original candidate is still the same as the new candidate, then we will parse & print the candidate one more time to pretty print into consistent classes. Luckily parsing is cached so there is no real downside overhead. Consistency (especially with arbitrary variants and values) will reduce your CSS file because there will be fewer "versions" of your class. Concretely, the pretty printing will apply changes such as: | Before | After | | ---------------------- | ----------------- | | `bg-[var(--my-color)]` | `bg-(--my-color)` | | `bg-[rgb(0,_0,_0)]` | `bg-[rgb(0,0,0)]` | Another big important reason for this change is that these classes on their own would have been migrated _if_ another migration was relevant for this candidate. This means that there are were some inconsistencies. E.g.: | Before | After | Reason | | ----------------------- | ---------------------- | ------------------------------------ | | `!bg-[var(--my-color)]` | `bg-(--my-color)!` | Because the `!` is in the wrong spot | | `bg-[var(--my-color)]` | `bg-[var(--my-color)]` | Because no migrations rand | As you can see, the way the `--my-color` variable is used, is different. This changes will make sure it will now always be consistent: | Before | After | | ----------------------- | ---------------------- | | `!bg-[var(--my-color)]` | `bg-(--my-color)!` | | `bg-[var(--my-color)]` | `bg-(--my-color)` | Yay! Of course, if you don't want these more cosmetic changes, you can always ignore the upgrade and revert these changes and only commit the changes you want. # Test plan - All existing tests still pass. - But I had to delete 1 test (we tested that Tailwind CSS v3 was required). - And had to mock the `version.isMajor` call to ensure we run the individual migration tests correctly. - Added new tests to test: 1. Migrating Tailwind CSS v4 projects works 1. Idempotency of the upgrade tool [ci-all]
2025-04-22 17:10:46 +02:00
"@types/postcss-import": "^14.0.3",
Update @types/semver 7.7.0 → 7.7.1 (patch) (#19005) 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/semver (7.7.0 → 7.7.1) · [Repo](https://github.com/DefinitelyTyped/DefinitelyTyped) 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>
2025-09-26 14:39:32 -04:00
"@types/semver": "^7.7.1"
Add initial codemod tooling (#14434) This PR adds some initial tooling for codemods. We are currently only interested in migrating CSS files, so we will be using PostCSS under the hood to do this. This PR also implements the "migrate `@apply`" codemod from #14412. The usage will look like this: ```sh npx @tailwindcss/upgrade ``` You can pass in CSS files to transform as arguments: ```sh npx @tailwindcss/upgrade src/**/*.css ``` But, if none are provided, it will search for CSS files in the current directory and its subdirectories. ``` ≈ tailwindcss v4.0.0-alpha.24 │ No files provided. Searching for CSS files in the current │ directory and its subdirectories… │ Migration complete. Verify the changes and commit them to │ your repository. ``` The tooling also requires the Git repository to be in a clean state. This is a common convention to ensure that everything is undo-able. If we detect that the git repository is dirty, we will abort the migration. ``` ≈ tailwindcss v4.0.0-alpha.24 │ Git directory is not clean. Please stash or commit your │ changes before migrating. │ You may use the `--force` flag to override this safety │ check. ``` --- This PR alsoo adds CSS codemods for migrating existing `@apply` directives to the new version. This PR has the ability to migrate the following cases: --- In v4, the convention is to put the important modifier `!` at the end of the utility class instead of right before it. This makes it easier to reason about, especially when you are variants. Input: ```css .foo { @apply !flex flex-col! hover:!items-start items-center; } ``` Output: ```css .foo { @apply flex! flex-col! hover:items-start! items-center; } ``` --- In v4 we don't support `!important` as a marker at the end of `@apply` directives. Instead, you can append the `!` to each utility class to make it `!important`. Input: ```css .foo { @apply flex flex-col !important; } ``` Output: ```css .foo { @apply flex! flex-col!; } ```
2024-09-18 16:45:43 +02:00
}
}
Reference in a new issue Copy permalink