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.2.3 (#19944)
2026-04-20 22:32:52 +02:00
"version": "4.2.3",
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:*",
Update dedent 1.7.0 → 1.7.1 (patch) (#19484) 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? #### ✳️ dedent (1.7.0 → 1.7.1) · [Repo](https://github.com/dmnd/dedent) · [Changelog](https://github.com/dmnd/dedent/blob/main/CHANGELOG.md) --- ![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-12-24 10:31:02 -05:00
"dedent": "1.7.1",
Update enhanced-resolve 5.18.4 → 5.19.0 (minor) (#19658) Here is everything you need to know about this update. Please take a good look at what changed and the test results before merging this pull request. ### What changed? #### ✳️ enhanced-resolve (5.18.4 → 5.19.0) · [Repo](https://github.com/webpack/enhanced-resolve) <details> <summary>Release Notes</summary> <h4><a href="https://github.com/webpack/enhanced-resolve/releases/tag/v5.19.0">5.19.0</a></h4> <blockquote><h3 dir="auto">Features</h3> <ul dir="auto"> <li>Added TsconfigPathsPlugin (replacement for <code class="notranslate">tsconfig-paths-webpack-plugin</code>) .</li> </ul></blockquote> <p><em>Does any of this look wrong? <a href="https://depfu.com/packages/npm/enhanced-resolve/feedback">Please let us know.</a></em></p> </details> <details> <summary>Commits</summary> <p><a href="https://github.com/webpack/enhanced-resolve/compare/e8a6ac9fdd88d579e20f4c487d6081d8e7b3093f...24ba2335540a77c9b019d66d28f995324866a718">See the full diff on Github</a>. The new version differs by 4 commits:</p> <ul> <li><a href="https://github.com/webpack/enhanced-resolve/commit/24ba2335540a77c9b019d66d28f995324866a718"><code>chore(release): 5.19.0</code></a></li> <li><a href="https://github.com/webpack/enhanced-resolve/commit/10dc3bc8b8734ab644d91abd979bc8ee4ad64532"><code>chore: update eslint config webpack (#471)</code></a></li> <li><a href="https://github.com/webpack/enhanced-resolve/commit/0d6c6c0fd9a156843d5d8e0cafa71450c1ee9e0a"><code>feat: added TsconfigPathsPlugin (replacement for tsconfig-paths-webpack-plugin) (#463)</code></a></li> <li><a href="https://github.com/webpack/enhanced-resolve/commit/958aa8921909f2a2662ae09f239a0f96b9b32c2d"><code>chore: migrate to npm from yarn (#469)</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-02-18 11:59:11 +01:00
"enhanced-resolve": "^5.19.0",
Revert "Update globby 15.0.0 → 16.0.0 (major) (#19357)" This reverts commit 28670a9b91033b6361a73b7e42c15da96fa96409.
2025-11-25 13:13:08 -05:00
"globby": "^15.0.0",
Template migrations: Migrate v3 prefixes to v4 (#14557) This PR adds a new migration that can migrate Tailwind CSS v3 style prefixes into Tailwind CSS v4. The migration is split into three separate pieces of work: 1. Firstly, we need to read the full JavaScript config to get the _old_ prefix option. This is necessary because in v4, we will not allow things like custom-separators for the prefix. From this option we will then try and compute a new prefix (in 90% of the cases this is going to just remove the trailing `-` but it can also work in more complex cases). 2. Then we migrate all Candidates. The important thing here is that we need to operate on the raw candidate string because by relying on `parseCandidate` (which we do for all other migrations) would not work, as the candidates are not valid in v4 syntax. More on that in a bit. 3. Lastly we also make sure to update the CSS config to include the new prefix. This is done by prepending the prefix option like so: ```css @import "tailwindcss" prefix(tw); ``` ### Migrating candidates The main difference between v3 prefixes and v4 prefixes is that in v3, the prefix was _part of the utility_ where as in v4 it is _always in front of the CSS class. So, for example, this candidate in v3: ``` hover:-tw-mr-4 ``` Would be converted to the following in v4: ``` tw:hover:-mr-4 ``` Since the first example _won't parse as a valid Candidate in v4, as the `tw-mr` utility does not exist, we have to operate on the raw candidate string first. To do this I created a fork of the `parseCandidate` function _without any validation of utilities or variants_. This is used to identify part of the candidate that is the `base` and then ensuring the `base` starts with the old prefix. We then remove this to create an "unprefixed" candidate that we validate against a version of the DesignSystem _with no prefixes configured_. If the variant is valid this way, we can then print it again with the `DesignSystem` that has the new prefix to get the migrated version. Since we set up the `DesignSystem` to include the new prefix, we can also be certain that migrations that happen afterwards would still disqualify candidates that aren't valid according to the new prefix policy. This does mean we need to have the prefix fixup be the first step in our pipeline. One interesting bit is that in v3, arbitrary properties did not require prefixes where as in v4 they do. So the following candidate: ``` [color:red] ``` Will be converted to: ``` tw:[color:red] ```
2024-10-01 18:04:08 +02:00
"jiti": "^2.0.0-beta.3",
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 (#19608) This PR bumps a bunch of dependencies. This also moves a few dependencies that we use in multiple packages to the pnpm catalog. Closes: #19603, #19604, #19576, #19575, #19573, #19565, #19547, #19546, #19545, #19609, #19581, #19620, #19619 - #19603 - #19604 - #19576 - #19575 - #19573 - #19565 - #19547 - #19546 - #19545 - #19609 - #19581 - https://github.com/tailwindlabs/tailwindcss/pull/19620 - #19620 - #19619 ## Test Plan All tests in CI should still pass. [ci-all]
2026-02-04 12:38:50 +01:00
"postcss": "^8.5.6",
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 postcss-selector-parser 7.1.0 → 7.1.1 (patch) (#19408) 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-selector-parser (7.1.0 → 7.1.1) · [Repo](https://github.com/postcss/postcss-selector-parser) · [Changelog](https://github.com/postcss/postcss-selector-parser/blob/master/CHANGELOG.md) <details> <summary>Release Notes</summary> <h4><a href="https://github.com/postcss/postcss-selector-parser/releases/tag/v7.1.1">7.1.1</a></h4> <blockquote><h1 dir="auto">7.1.1</h1> <ul dir="auto"> <li>perf: replace startsWith with strict equality (<a href="https://bounce.depfu.com/github.com/postcss/postcss-selector-parser/pull/308">#308</a>)</li> <li>fix(types): add walkUniversal declaration (<a href="https://bounce.depfu.com/github.com/postcss/postcss-selector-parser/pull/311">#311</a>)</li> </ul></blockquote> <p><em>Does any of this look wrong? <a href="https://depfu.com/packages/npm/postcss-selector-parser/feedback">Please let us know.</a></em></p> </details> <details> <summary>Commits</summary> <p><a href="https://github.com/postcss/postcss-selector-parser/compare/ea6cd9324b4be90a4c529c3602deefbc4a2d7a82...cf6637ed6a2dbc9d24bc3a1d04ec7ac4629dd856">See the full diff on Github</a>. The new version differs by 6 commits:</p> <ul> <li><a href="https://github.com/postcss/postcss-selector-parser/commit/cf6637ed6a2dbc9d24bc3a1d04ec7ac4629dd856"><code>chore(release): 7.1.1</code></a></li> <li><a href="https://github.com/postcss/postcss-selector-parser/commit/54cef58801b32f9c4101cea5b8c7bc0432238466"><code>fix(types): add `walkUniversal` declaration (#311)</code></a></li> <li><a href="https://github.com/postcss/postcss-selector-parser/commit/3da25fecba8110ccda23b69de3b00dde5bd1cd5b"><code>perf: replace startsWith with strict equality (#308)</code></a></li> <li><a href="https://github.com/postcss/postcss-selector-parser/commit/b647f7c70fefa3bdf118229705002b5a886bda34"><code>ci: test on Node.js 24 (#307)</code></a></li> <li><a href="https://github.com/postcss/postcss-selector-parser/commit/337129d1e3174d131717113c2ad131325b72d24e"><code>chore: replace abandoned pkg coveralls with coveralls-next</code></a></li> <li><a href="https://github.com/postcss/postcss-selector-parser/commit/6343f29e08c6fa9c1d2610fb72bf851b1aeffe69"><code>ci: test on Node.js 22 (#301)</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-12-04 10:55:11 -05:00
"postcss-selector-parser": "^7.1.1",
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 semver 7.7.3 → 7.7.4 (patch) (#19667) 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? #### ✳️ semver (7.7.3 → 7.7.4) · [Repo](https://github.com/npm/node-semver) · [Changelog](https://github.com/npm/node-semver/blob/main/CHANGELOG.md) <details> <summary>Release Notes</summary> <h4><a href="https://github.com/npm/node-semver/releases/tag/v7.7.4">7.7.4</a></h4> <blockquote><h2 dir="auto"> <a href="https://bounce.depfu.com/github.com/npm/node-semver/compare/v7.7.3...v7.7.4">7.7.4</a> (2026-01-16)</h2> <h3 dir="auto">Bug Fixes</h3> <ul dir="auto"> <li> <a href="https://bounce.depfu.com/github.com/npm/node-semver/commit/a29faa5f3309a01c8e5aeb965fb5c02c4c4e80e2"><code class="notranslate">a29faa5</code></a> <a href="https://bounce.depfu.com/github.com/npm/node-semver/pull/835">#835</a> cli: pass options to semver.valid() for loose version validation (<a href="https://bounce.depfu.com/github.com/npm/node-semver/pull/835">#835</a>) (<a href="https://bounce.depfu.com/github.com/mldangelo">@mldangelo</a>)</li> </ul> <h3 dir="auto">Documentation</h3> <ul dir="auto"> <li> <a href="https://bounce.depfu.com/github.com/npm/node-semver/commit/1d28d5e82de16163daf721a7c76fff93e0d333ab"><code class="notranslate">1d28d5e</code></a> <a href="https://bounce.depfu.com/github.com/npm/node-semver/pull/836">#836</a> fix typos and update -n CLI option documentation (<a href="https://bounce.depfu.com/github.com/npm/node-semver/pull/836">#836</a>) (<a href="https://bounce.depfu.com/github.com/mldangelo">@mldangelo</a>)</li> </ul> <h3 dir="auto">Dependencies</h3> <ul dir="auto"> <li> <a href="https://bounce.depfu.com/github.com/npm/node-semver/commit/120968b76760cb0db85a72bde2adedd0e9628793"><code class="notranslate">120968b</code></a> <a href="https://bounce.depfu.com/github.com/npm/node-semver/pull/840">#840</a> <code class="notranslate">@npmcli/template-oss@4.29.0</code> (<a href="https://bounce.depfu.com/github.com/npm/node-semver/pull/840">#840</a>)</li> </ul> <h3 dir="auto">Chores</h3> <ul dir="auto"> <li> <a href="https://bounce.depfu.com/github.com/npm/node-semver/commit/44d7130c60cedd3703048aa671bb1d659b79ab07"><code class="notranslate">44d7130</code></a> <a href="https://bounce.depfu.com/github.com/npm/node-semver/pull/824">#824</a> bump @npmcli/eslint-config from 5.1.0 to 6.0.0 (<a href="https://bounce.depfu.com/github.com/npm/node-semver/pull/824">#824</a>) (<a href="https://bounce.depfu.com/github.com/dependabot">@dependabot</a>[bot])</li> <li> <a href="https://bounce.depfu.com/github.com/npm/node-semver/commit/70735767b68a1775eb67ac816b183b4a422101f4"><code class="notranslate">7073576</code></a> <a href="https://bounce.depfu.com/github.com/npm/node-semver/pull/820">#820</a> reorder parameters in invalid-versions.js test (<a href="https://bounce.depfu.com/github.com/npm/node-semver/pull/820">#820</a>) (<a href="https://bounce.depfu.com/github.com/reggi">@reggi</a>)</li> <li> <a href="https://bounce.depfu.com/github.com/npm/node-semver/commit/5816d4cfd6d85169527a2bc22fbd5bf4c64f34e3"><code class="notranslate">5816d4c</code></a> <a href="https://bounce.depfu.com/github.com/npm/node-semver/pull/829">#829</a> bump @npmcli/template-oss from 4.28.0 to 4.28.1 (<a href="https://bounce.depfu.com/github.com/npm/node-semver/pull/829">#829</a>) (<a href="https://bounce.depfu.com/github.com/dependabot">@dependabot</a>[bot], <a href="https://bounce.depfu.com/github.com/npm-cli-bot">@npm-cli-bot</a>)</li> </ul></blockquote> <p><em>Does any of this look wrong? <a href="https://depfu.com/packages/npm/semver/feedback">Please let us know.</a></em></p> </details> <details> <summary>Commits</summary> <p><a href="https://github.com/npm/node-semver/compare/a25789b09b1192fa8414c35f2cd679ae2e1d5192...5993c2e42bdf17c5f03e6360da51bc707fcee460">See the full diff on Github</a>. The new version differs by 10 commits:</p> <ul> <li><a href="https://github.com/npm/node-semver/commit/5993c2e42bdf17c5f03e6360da51bc707fcee460"><code>chore: release 7.7.4 (#839)</code></a></li> <li><a href="https://github.com/npm/node-semver/commit/120968b76760cb0db85a72bde2adedd0e9628793"><code>deps: @npmcli/template-oss@4.29.0 (#840)</code></a></li> <li><a href="https://github.com/npm/node-semver/commit/a29faa5f3309a01c8e5aeb965fb5c02c4c4e80e2"><code>fix(cli): pass options to semver.valid() for loose version validation (#835)</code></a></li> <li><a href="https://github.com/npm/node-semver/commit/1d28d5e82de16163daf721a7c76fff93e0d333ab"><code>docs: fix typos and update -n CLI option documentation (#836)</code></a></li> <li><a href="https://github.com/npm/node-semver/commit/5816d4cfd6d85169527a2bc22fbd5bf4c64f34e3"><code>chore: bump @npmcli/template-oss from 4.28.0 to 4.28.1 (#829)</code></a></li> <li><a href="https://github.com/npm/node-semver/commit/ab9e28a582f524e8d40157f3d2b75fcc764d0765"><code>chore: bump @npmcli/template-oss from 4.27.1 to 4.28.0 (#827)</code></a></li> <li><a href="https://github.com/npm/node-semver/commit/44d7130c60cedd3703048aa671bb1d659b79ab07"><code>chore: bump @npmcli/eslint-config from 5.1.0 to 6.0.0 (#824)</code></a></li> <li><a href="https://github.com/npm/node-semver/commit/70735767b68a1775eb67ac816b183b4a422101f4"><code>chore: reorder parameters in invalid-versions.js test (#820)</code></a></li> <li><a href="https://github.com/npm/node-semver/commit/16a35f5df4bb142d781229a09158c4e9970c1f5a"><code>chore: bump @npmcli/template-oss from 4.26.0 to 4.27.1 (#823)</code></a></li> <li><a href="https://github.com/npm/node-semver/commit/3a3459da45389bd024ac907cbc21ca5a24beaa05"><code>chore: bump @npmcli/template-oss from 4.25.1 to 4.26.0 (#818)</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-02-18 11:58:49 +01:00
"semver": "^7.7.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