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.4 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",
Prepare v4.0.9 release (#16804) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-02-25 17:33:28 +01:00
"version": "4.0.9",
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:*",
Fix crash during upgrade when content globs escape root of project (#14896) This PR fixes an issue where globs in you `content` configuration escape the current "root" of the project. This can happen if you have a folder, and you need to look up in the tree (e.g.: when looking at another package in a monorepo, or in case of a Laravel project where you want to look at mail templates). This applies a similar strategy we already implement on the Rust side. 1. Expand braces in the globs 2. Move static parts of the `pattern` to the `base` of the glob entry object --- Given a project setup like this: ``` . ├── admin │   ├── my-tailwind.config.ts │   └── src │   ├── abc.jpg │   ├── index.html │   ├── index.js │   └── styles │   └── input.css ├── dashboard │   ├── src │   │   ├── index.html │   │   ├── index.js │   │   ├── input.css │   │   └── pickaday.css │   └── tailwind.config.ts ├── package-lock.json ├── package.json ├── postcss.config.js └── unrelated └── index.html 7 directories, 14 files ``` If you then have this config: ```ts // admin/my-tailwind.config.ts export default { content: { relative: true, files: ['./src/**/*.html', '../dashboard/src/**/*.html'], // ^^ this is the important part, which escapes // the current root of the project. }, theme: { extend: { colors: { primary: 'red', }, }, }, } ``` Then before this change, running the command looks like this: <img width="1760" alt="image" src="https://github.com/user-attachments/assets/60e2dfc7-3751-4432-80e3-8b4b8f1083d4"> After this change, running the command looks like this: <img width="1452" alt="image" src="https://github.com/user-attachments/assets/5c47182c-119c-4732-a253-2dace7086049"> --------- Co-authored-by: Philipp Spiess <hello@philippspiess.com>
2024-11-07 13:22:25 +01:00
"braces": "^3.0.3",
Add codemod for border style compatibility (#14746) This PR adds a codemod that ensures that the border styles from Tailwind CSS v3 work as expected once your project is migrated to Tailwind CSS v4. In Tailwind CSS v3, the default border color is `colors.gray.200` and in Tailwind CSS v4 the default border color is `currentColor`. Similarly in Tailwind CSS v3, DOM elements such as `input`, `select`, and `textarea` have a border width of `0px`, in Tailwind CSS v4, we don't change the border width of these elements and keep them as `1px`. If your project happens to already use the same value for the default border color (`currentColor`) as we use in Tailwind CSS v4, then nothing happens. But this is very unlikely, so we will make sure that we honor your `borderColor.DEFAULT` value. If you didn't change the default values in your `tailwind.config.js`, then we will inject compatibility CSS using the default Tailwind CSS v3 values to ensure the default color and width are applied correctly.
2024-10-22 17:41:50 +00:00
"dedent": "1.5.3",
Update enhanced-resolve 5.18.0 → 5.18.1 (patch) (#16439)
2025-02-11 18:02:29 +01:00
"enhanced-resolve": "^5.18.1",
Update globby 14.0.2 → 14.1.0 (minor) (#16564)
2025-02-17 12:06:53 +01:00
"globby": "^14.1.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",
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
"postcss": "^8.4.41",
"postcss-import": "^16.1.0",
Update postcss-selector-parser 7.0.0 → 7.1.0 (minor) (#16558)
2025-02-17 12:07:13 +01:00
"postcss-selector-parser": "^7.1.0",
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 tree-sitter 0.22.1 → 0.22.4 (minor) (#15585)
2025-01-10 10:26:48 +01:00
"tree-sitter": "^0.22.4",
Update tree-sitter-typescript 0.23.0 → 0.23.2 (minor) (#15026)
2024-11-18 10:23:22 +01:00
"tree-sitter-typescript": "^0.23.2",
Ensure clients pin the `tailwindcss` version (#15011) We noticed that in the current alpha 34 release, the `package.json` file of the `@tailwindcss/node` package only defines `tailwindcss` as a dev dependency. This makes it very easy for version mismatches to happen when a v3 version (or an earlier v4 alpha for that matter) was installed in the same project: ```json { "name": "@tailwindcss/node", "version": "4.0.0-alpha.34", "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-node" }, "bugs": "https://github.com/tailwindlabs/tailwindcss/issues", "homepage": "https://tailwindcss.com", "files": [ "dist/" ], "publishConfig": { "provenance": true, "access": "public" }, "exports": { ".": { "types": "./dist/index.d.ts", "import": "./dist/index.mjs", "require": "./dist/index.js" }, "./require-cache": { "types": "./dist/require-cache.d.ts", "default": "./dist/require-cache.js" }, "./esm-cache-loader": { "types": "./dist/esm-cache.loader.d.mts", "default": "./dist/esm-cache.loader.mjs" } }, "devDependencies": { "tailwindcss": "4.0.0-alpha.34" }, "dependencies": { "enhanced-resolve": "^5.17.1", "jiti": "^2.0.0-beta.3" }, "scripts": { "build": "tsup-node", "dev": "pnpm run build -- --watch" } } ``` Furthermore, we were trying to fix issues where our integration test setup could not install `tailwindcss@3` because of how we did pnpm overrides. This PR fixes this by: - Ensuring every client that calls into `tailwindcss` core marks it as a version-pinned dependency. You are still required to install `tailwindcss` in your project along side a client (e.g. `@tailwindcss/vite`) but we now only use your installed version for importing the respective `.css` files. For the core logic, we are now requiring each package to use `tailwindcss` at the same version. This should help resolve issues like https://github.com/tailwindlabs/tailwindcss/discussions/14652 - We tried to eliminate the dependency on `tailwindcss` from the `@tailwindcss/upgrade` package. Unfortunately this is not possible to do right now because we need to load the CSS files from v4 to create the right environment. In a future version we could bundle the required CSS files with `@tailwidncss/upgrade` but it doesn't seem necessary for now. - We then changed our integration test overrides to only override the `tailwindcss` package that are dependencies of the known list of packages that we have `tailwindcss` dependencies on: `@tailwindcss/node` and `@tailwindcss/upgrade`. This ensures that we can install v3 of `tailwindcss` in the integration tests and it will work. Something we want to do for some upgrade tests. # Test plan Integration work again. Furthermore we added a quick setup with the CLI using the local tarballs and ensured it works: ```bash pnpm init pnpm install ../../tailwindcss/dist/tailwindcss-cli.tgz pnpm install ../../tailwindcss/dist/tailwindcss.tgz echo '@import "tailwindcss";' > index.css echo '<div class="underline"></div>' > index.html pnpm tailwindcss -i index.css -o out.css cat out.css ```
2024-11-15 17:18:48 +01:00
"tailwindcss": "workspace:*"
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": {
Update @types/braces 3.0.4 → 3.0.5 (patch) (#15612)
2025-01-13 10:53:47 +01:00
"@types/braces": "^3.0.5",
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
"@types/node": "catalog:",
Add codemod for border style compatibility (#14746) This PR adds a codemod that ensures that the border styles from Tailwind CSS v3 work as expected once your project is migrated to Tailwind CSS v4. In Tailwind CSS v3, the default border color is `colors.gray.200` and in Tailwind CSS v4 the default border color is `currentColor`. Similarly in Tailwind CSS v3, DOM elements such as `input`, `select`, and `textarea` have a border width of `0px`, in Tailwind CSS v4, we don't change the border width of these elements and keep them as `1px`. If your project happens to already use the same value for the default border color (`currentColor`) as we use in Tailwind CSS v4, then nothing happens. But this is very unlikely, so we will make sure that we honor your `borderColor.DEFAULT` value. If you didn't change the default values in your `tailwind.config.js`, then we will inject compatibility CSS using the default Tailwind CSS v3 values to ensure the default color and width are applied correctly.
2024-10-22 17:41:50 +00:00
"@types/postcss-import": "^14.0.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
}
}
Reference in a new issue Copy permalink