wrapper/tailwindcss
1
0
Fork 0
Code Issues Pull requests Projects Releases 1 Packages Wiki Activity Actions
tailwindcss/integrations/postcss/multi-root.test.ts

51 lines
1.4 KiB
TypeScript
Raw Permalink Normal View History

Add integration tests for multi-root builds (#14564) When your Vite or postcss project has multiple Tailwind CSS roots with different configs, they should not influence each other (with the exception of the same candidates being used).
2024-10-01 17:00:20 +02:00
import { candidate, css, html, js, json, test } from '../utils'
test(
'production build',
{
fs: {
'package.json': json`
{
"dependencies": {
"postcss": "^8",
"postcss-cli": "^10",
"tailwindcss": "workspace:^",
"@tailwindcss/postcss": "workspace:^"
}
}
`,
'postcss.config.js': js`
module.exports = {
plugins: {
'@tailwindcss/postcss': {},
},
}
`,
'index.html': html`
<div class="one:underline two:underline"></div>
`,
'src/shared.css': css`
Make `@reference` emit variable fallbacks instead of CSS variable declarations (#16774) Fixes #16725 When using `@reference "tailwindcss";` inside a separate CSS root (e.g. Svelte `<style>` components, CSS modules, etc.), we have no guarantee that the CSS variables will be defined in the main stylesheet (or if there even is one). To work around potential issues with this we decided in #16676 that we would emit all used CSS variables from the `@theme` inside the `@reference` block. However, this is not only a bit surprising but also unexpected in CSS modules and Next.js that **requires CSS module files to only create scope-able declarations**. To fix this issue, we decided to not emit CSS variables but instead ensure all `var(…)` calls we create for theme values in reference mode will simply have their fallback value added. This ensures styles work as-expected even if the root Tailwind file does not pick up the variable as being used or _if you don't add a root at all_. Furthermore we do not duplicate any variable declarations across your stylesheets and you still have the ability to change variables at runtime. ## Test plan - Updated snapshots everywhere (see diff) - New Next.js CSS modules integration test
2025-02-25 11:36:43 +01:00
@reference 'tailwindcss/theme';
Add integration tests for multi-root builds (#14564) When your Vite or postcss project has multiple Tailwind CSS roots with different configs, they should not influence each other (with the exception of the same candidates being used).
2024-10-01 17:00:20 +02:00
@import 'tailwindcss/utilities';
`,
'src/root1.css': css`
@import './shared.css';
Implement `@variant` (#15663) This PR replaces `@variant` with `@custom-variant` for registering custom variants via your CSS. In addition, this PR introduces `@variant` that can be used in your CSS to use a variant while writing custom CSS. E.g.: ```css .btn { background: white; @variant dark { background: black; } } ``` Compiles to: ```css .btn { background: white; } @media (prefers-color-scheme: dark) { .btn { background: black; } } ``` For backwards compatibility, the `@variant` rules that don't have a body and are defined inline: ```css @variant hocus (&:hover, &:focus); ``` And `@variant` rules that are defined with a body and a `@slot`: ```css @variant hocus { &:hover, &:focus { @slot; } } ``` Will automatically be upgraded to `@custom-variant` internally, so no breaking changes are introduced with this PR. --- TODO: - [x] ~~Decide whether we want to allow multiple variants and if so, what syntax should be used. If not, nesting `@variant <variant> {}` will be the way to go.~~ Only a single `@variant <variant>` can be used, if you want to use multiple, nesting should be used: ```css .foo { @variant hover { @variant focus { color: red; } } } ```
2025-01-21 10:20:35 -05:00
@custom-variant one (&:is([data-root='1']));
Add integration tests for multi-root builds (#14564) When your Vite or postcss project has multiple Tailwind CSS roots with different configs, they should not influence each other (with the exception of the same candidates being used).
2024-10-01 17:00:20 +02:00
`,
'src/root2.css': css`
@import './shared.css';
Implement `@variant` (#15663) This PR replaces `@variant` with `@custom-variant` for registering custom variants via your CSS. In addition, this PR introduces `@variant` that can be used in your CSS to use a variant while writing custom CSS. E.g.: ```css .btn { background: white; @variant dark { background: black; } } ``` Compiles to: ```css .btn { background: white; } @media (prefers-color-scheme: dark) { .btn { background: black; } } ``` For backwards compatibility, the `@variant` rules that don't have a body and are defined inline: ```css @variant hocus (&:hover, &:focus); ``` And `@variant` rules that are defined with a body and a `@slot`: ```css @variant hocus { &:hover, &:focus { @slot; } } ``` Will automatically be upgraded to `@custom-variant` internally, so no breaking changes are introduced with this PR. --- TODO: - [x] ~~Decide whether we want to allow multiple variants and if so, what syntax should be used. If not, nesting `@variant <variant> {}` will be the way to go.~~ Only a single `@variant <variant>` can be used, if you want to use multiple, nesting should be used: ```css .foo { @variant hover { @variant focus { color: red; } } } ```
2025-01-21 10:20:35 -05:00
@custom-variant two (&:is([data-root='2']));
Add integration tests for multi-root builds (#14564) When your Vite or postcss project has multiple Tailwind CSS roots with different configs, they should not influence each other (with the exception of the same candidates being used).
2024-10-01 17:00:20 +02:00
`,
},
},
async ({ fs, exec }) => {
await exec('pnpm postcss src/*.css -d dist')
await fs.expectFileToContain('dist/root1.css', [candidate`one:underline`])
await fs.expectFileNotToContain('dist/root1.css', [candidate`two:underline`])
await fs.expectFileNotToContain('dist/root2.css', [candidate`one:underline`])
await fs.expectFileToContain('dist/root2.css', [candidate`two:underline`])
},
)
Reference in a new issue Copy permalink