This website requires JavaScript.
Explore
Help
Sign in
wrapper
/
tailwindcss
Watch
1
Star
0
Fork
You've already forked tailwindcss
0
Code
Issues
Pull requests
Projects
Releases
1
Packages
Wiki
Activity
Actions
aa665d3dcf
tailwindcss
/
packages
/
@tailwindcss-upgrade
/
tsconfig.json
7 lines
109 B
JSON
Raw
Normal View
History
Unescape
Escape
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
{
"extends"
:
"../tsconfig.base.json"
,
Detect and migrate static plugin usages (#14648) This PR builds on top of the new [JS config to CSS migration](https://github.com/tailwindlabs/tailwindcss/pull/14651) and extends it to support migrating _static_ plugins. What are _static_ plugins you might ask? Static plugins are plugins where we can statically determine that these are coming from a different file (so there is nothing inside the JS config that creates them). An example for this is this config file: ```js import typographyPlugin from '@tailwindcss/typography' import { type Config } from 'tailwindcss' export default { content: ['./src/**/*.{js,jsx,ts,tsx}'], darkMode: 'selector', plugins: [typographyPlugin], } satisfies Config ``` Here, the `plugins` array only has one element and it is a static import from the `@tailwindcss/typography` module. In this PR we attempt to parse the config file via Tree-sitter to extract the following information from this file: - What are the contents of the `plugins` array - What are statically imported resources from the file We then check if _all_ entries in the `plugins` array are either static resources or _strings_ (something I saw working in some tests but I’m not sure it still does). We migrate the JS config file to CSS if all plugins are static and we can migrate them to CSS `@plugin` calls. ## Todo This will need to be rebased after the updated tests in #14648
2024-10-14 17:45:36 +02:00
"compilerOptions"
:
{
"allowSyntheticDefaultImports"
:
true
}
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