tailwindcss/packages/@tailwindcss-upgrade/tsconfig.json

{
  "extends": "../tsconfig.base.json",
  "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			`{`
			`"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": {`
Internal refactor, introduce `AtRule` (#14802) This PR introduces an internal refactor where we introduce the `AtRule` CSS Node in our AST. The motivation for this is that in a lot of places we need to differentiate between a `Rule` and an `AtRule`. We often do this with code that looks like this: ```ts rule.selector[0] === '@' && rule.selector.startsWith('@media') ``` Another issue we have is that we often need to check for `'@media '` including the space, because we don't want to match `@mediafoobar` if somebody has this in their CSS. Alternatively, if you CSS is minified then it could be that you have a rule that looks like `@media(width>=100px)`, in this case we _also_ have to check for `@media(`. Here is a snippet of code that we have in our codebase: ```ts // Find at-rules rules if (node.kind === 'rule') { if ( node.selector[0] === '@' && (node.selector.startsWith('@media ') \|\| node.selector.startsWith('@media(') \|\| node.selector.startsWith('@custom-media ') \|\| node.selector.startsWith('@custom-media(') \|\| node.selector.startsWith('@container ') \|\| node.selector.startsWith('@container(') \|\| node.selector.startsWith('@supports ') \|\| node.selector.startsWith('@supports(')) && node.selector.includes(THEME_FUNCTION_INVOCATION) ) { node.selector = substituteFunctionsInValue(node.selector, resolveThemeValue) } } ``` Which will now be replaced with a much simpler version: ```ts // Find at-rules rules if (node.kind === 'at-rule') { if ( (node.name === '@media' \|\| node.name === '@custom-media' \|\| node.name === '@container' \|\| node.name === '@supports') && node.params.includes(THEME_FUNCTION_INVOCATION) ) { node.params = substituteFunctionsInValue(node.params, resolveThemeValue) } } ``` Checking for all the cases from the first snippet is not the end of the world, but it is error prone. It's easy to miss a case. A direct comparison is also faster than comparing via the `startsWith(…)` function. --- Note: this is only a refactor without changing other code _unless_ it was required to make the tests pass. The tests themselves are all passing and none of them changed (because the behavior should be the same). The one exception is the tests where we check the parsed AST, which now includes `at-rule` nodes instead of `rule` nodes when we have an at-rule. 2024-10-29 01:17:25 +01:00			`"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			`}`