tailwindcss/tests/custom-plugins.test.js

1977 lines
45 KiB
JavaScript
Raw Normal View History

import createPlugin from '../src/public/create-plugin'
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
import { run, html, css, defaults } from './util/run'
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test('plugins can create utilities with object syntax', () => {
let config = {
content: [
{
raw: html`<div class="custom-object-fill custom-object-contain custom-object-cover"></div>`,
},
],
plugins: [
function ({ addUtilities }) {
addUtilities({
'.custom-object-fill': {
'object-fit': 'fill',
},
'.custom-object-contain': {
'object-fit': 'contain',
},
'.custom-object-cover': {
'object-fit': 'cover',
},
})
},
],
}
return run('@tailwind utilities', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
.custom-object-fill {
object-fit: fill;
}
.custom-object-contain {
object-fit: contain;
}
.custom-object-cover {
object-fit: cover;
}
`)
})
})
test('plugins can create utilities with arrays of objects', () => {
let config = {
content: [
{
raw: html`<div class="custom-object-fill custom-object-contain custom-object-cover"></div>`,
},
],
plugins: [
function ({ addUtilities }) {
addUtilities([
{
'.custom-object-fill': {
'object-fit': 'fill',
},
'.custom-object-contain': {
'object-fit': 'contain',
},
'.custom-object-cover': {
'object-fit': 'cover',
},
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
},
])
},
],
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
return run('@tailwind utilities', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
.custom-object-fill {
object-fit: fill;
}
.custom-object-contain {
object-fit: contain;
}
.custom-object-cover {
object-fit: cover;
}
`)
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test('plugins can create utilities with raw PostCSS nodes', () => {
let config = {
content: [
{
raw: html`<div class="custom-object-fill custom-object-contain custom-object-cover"></div>`,
},
],
plugins: [
function ({ addUtilities, postcss }) {
addUtilities([
postcss.rule({ selector: '.custom-object-fill' }).append([
postcss.decl({
prop: 'object-fit',
value: 'fill',
}),
]),
postcss.rule({ selector: '.custom-object-contain' }).append([
postcss.decl({
prop: 'object-fit',
value: 'contain',
}),
]),
postcss.rule({ selector: '.custom-object-cover' }).append([
postcss.decl({
prop: 'object-fit',
value: 'cover',
}),
]),
])
},
],
}
return run('@tailwind utilities', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
.custom-object-fill {
object-fit: fill;
}
.custom-object-contain {
object-fit: contain;
}
.custom-object-cover {
object-fit: cover;
}
`)
})
})
test('plugins can create utilities with mixed object styles and PostCSS nodes', () => {
let config = {
content: [
{
raw: html`<div class="custom-object-fill custom-object-contain custom-object-cover"></div>`,
},
],
plugins: [
function ({ addUtilities, postcss }) {
addUtilities([
{
'.custom-object-fill': {
objectFit: 'fill',
},
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
},
postcss.rule({ selector: '.custom-object-contain' }).append([
postcss.decl({
prop: 'object-fit',
value: 'contain',
}),
]),
postcss.rule({ selector: '.custom-object-cover' }).append([
postcss.decl({
prop: 'object-fit',
value: 'cover',
}),
]),
])
},
],
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
return run('@tailwind utilities', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
.custom-object-fill {
object-fit: fill;
}
.custom-object-contain {
object-fit: contain;
}
.custom-object-cover {
object-fit: cover;
}
`)
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test('plugins can create components with object syntax', () => {
let config = {
content: [
{
raw: html`<button class="btn-blue"></button>`,
},
],
plugins: [
function ({ addComponents }) {
addComponents({
'.btn-blue': {
backgroundColor: 'blue',
color: 'white',
padding: '.5rem 1rem',
borderRadius: '.25rem',
},
'.btn-blue:hover': {
backgroundColor: 'darkblue',
},
})
},
],
}
return run('@tailwind components', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
.btn-blue {
color: #fff;
background-color: #00f;
border-radius: 0.25rem;
padding: 0.5rem 1rem;
}
.btn-blue:hover {
background-color: #00008b;
}
`)
})
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test('plugins can add base styles with object syntax', () => {
let config = {
content: [
{
raw: html`<img /><button></button>`,
},
],
plugins: [
function ({ addBase }) {
addBase({
img: {
maxWidth: '100%',
},
button: {
fontFamily: 'inherit',
},
})
},
],
corePlugins: { preflight: false },
}
return run('@tailwind base', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
img {
max-width: 100%;
}
button {
font-family: inherit;
}
${defaults}
`)
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test('plugins can add base styles with raw PostCSS nodes', () => {
let config = {
content: [
{
raw: html`<img /><button></button>`,
},
],
plugins: [
function ({ addBase, postcss }) {
addBase([
postcss.rule({ selector: 'img' }).append([
postcss.decl({
prop: 'max-width',
value: '100%',
}),
]),
postcss.rule({ selector: 'button' }).append([
postcss.decl({
prop: 'font-family',
value: 'inherit',
}),
]),
])
},
],
corePlugins: { preflight: false },
}
return run('@tailwind base', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
img {
max-width: 100%;
}
button {
font-family: inherit;
}
${defaults}
`)
})
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test('plugins can create components with raw PostCSS nodes', () => {
let config = {
content: [
{
raw: html`<button class="btn-blue"></button>`,
},
],
plugins: [
function ({ addComponents, postcss }) {
addComponents([
postcss.rule({ selector: '.btn-blue' }).append([
postcss.decl({
prop: 'background-color',
value: 'blue',
}),
postcss.decl({
prop: 'color',
value: 'white',
}),
postcss.decl({
prop: 'padding',
value: '.5rem 1rem',
}),
postcss.decl({
prop: 'border-radius',
value: '.25rem',
}),
]),
postcss.rule({ selector: '.btn-blue:hover' }).append([
postcss.decl({
prop: 'background-color',
value: 'darkblue',
}),
]),
])
},
],
}
return run('@tailwind components', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
.btn-blue {
color: #fff;
background-color: #00f;
border-radius: 0.25rem;
padding: 0.5rem 1rem;
}
.btn-blue:hover {
background-color: #00008b;
}
`)
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test('plugins can create components with mixed object styles and raw PostCSS nodes', () => {
let config = {
content: [
{
raw: html`<button class="btn-blue"></button>`,
},
],
plugins: [
function ({ addComponents, postcss }) {
addComponents([
postcss.rule({ selector: '.btn-blue' }).append([
postcss.decl({
prop: 'background-color',
value: 'blue',
}),
postcss.decl({
prop: 'color',
value: 'white',
}),
postcss.decl({
prop: 'padding',
value: '.5rem 1rem',
}),
postcss.decl({
prop: 'border-radius',
value: '.25rem',
}),
]),
{
'.btn-blue:hover': {
backgroundColor: 'darkblue',
},
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
},
])
},
],
}
return run('@tailwind components', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
.btn-blue {
color: #fff;
background-color: #00f;
border-radius: 0.25rem;
padding: 0.5rem 1rem;
}
.btn-blue:hover {
background-color: #00008b;
}
`)
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test('plugins can create components with media queries with object syntax', () => {
let config = {
content: [
{
raw: html`<div class="custom-container"></div>`,
},
],
plugins: [
function ({ addComponents }) {
addComponents({
'.custom-container': {
width: '100%',
},
'@media (min-width: 100px)': {
'.custom-container': {
maxWidth: '100px',
},
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
},
'@media (min-width: 200px)': {
'.custom-container': {
maxWidth: '200px',
},
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
},
'@media (min-width: 300px)': {
'.custom-container': {
maxWidth: '300px',
},
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
},
})
},
],
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
return run('@tailwind components', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
.custom-container {
width: 100%;
}
@media (min-width: 100px) {
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
.custom-container {
max-width: 100px;
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
}
@media (min-width: 200px) {
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
.custom-container {
max-width: 200px;
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
}
@media (min-width: 300px) {
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
.custom-container {
max-width: 300px;
}
}
`)
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test('media queries can be defined multiple times using objects-in-array syntax', () => {
let config = {
content: [
{
raw: html`<div class="custom-container"></div>
<button class="btn"></button>`,
},
],
plugins: [
function ({ addComponents }) {
addComponents([
{
'.custom-container': {
width: '100%',
},
'@media (min-width: 100px)': {
'.custom-container': {
maxWidth: '100px',
},
},
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
},
{
'.btn': {
padding: '1rem .5rem',
display: 'block',
},
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
'@media (min-width: 100px)': {
'.btn': {
display: 'inline-block',
},
},
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
},
])
},
],
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
return run('@tailwind components', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
.custom-container {
width: 100%;
}
@media (min-width: 100px) {
.custom-container {
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
max-width: 100px;
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
}
.btn {
padding: 1rem 0.5rem;
display: block;
}
@media (min-width: 100px) {
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
.btn {
display: inline-block;
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
}
`)
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test('plugins can create nested rules', () => {
let config = {
content: [{ raw: html`<button class="btn-blue"></button>` }],
plugins: [
function ({ addComponents }) {
addComponents({
'.btn-blue': {
backgroundColor: 'blue',
color: 'white',
padding: '.5rem 1rem',
borderRadius: '.25rem',
'&:hover': {
backgroundColor: 'darkblue',
},
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
'@media (min-width: 500px)': {
'&:hover': {
backgroundColor: 'orange',
},
},
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
'> a': {
color: 'red',
},
'h1 &': {
color: 'purple',
},
},
})
},
],
}
return run('@tailwind components', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
.btn-blue {
color: #fff;
background-color: #00f;
border-radius: 0.25rem;
padding: 0.5rem 1rem;
}
.btn-blue:hover {
background-color: #00008b;
}
@media (min-width: 500px) {
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
.btn-blue:hover {
background-color: orange;
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
}
.btn-blue > a {
color: red;
}
h1 .btn-blue {
color: purple;
}
`)
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test('plugins can create rules with escaped selectors', () => {
let config = {
content: [{ raw: html`<div class="custom-top-1/4"></div>` }],
plugins: [
function ({ e, addUtilities }) {
addUtilities({
[`.${e('custom-top-1/4')}`]: {
top: '25%',
},
})
},
],
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
return run('@tailwind utilities', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
.custom-top-1\/4 {
top: 25%;
}
`)
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test('plugins can access the current config', () => {
let config = {
content: [{ raw: html`<div class="custom-container"></div>` }],
plugins: [
function ({ addComponents, config }) {
let containerClasses = [
{
'.custom-container': {
width: '100%',
},
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
},
]
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
for (let maxWidth of Object.values(config('theme.customScreens'))) {
containerClasses.push({
[`@media (min-width: ${maxWidth})`]: {
'.custom-container': { maxWidth },
},
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
})
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
addComponents(containerClasses)
},
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
],
theme: {
customScreens: {
sm: '576px',
md: '768px',
lg: '992px',
xl: '1200px',
},
},
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
return run('@tailwind components', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
.custom-container {
width: 100%;
}
@media (min-width: 576px) {
.custom-container {
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
max-width: 576px;
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
}
@media (min-width: 768px) {
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
.custom-container {
max-width: 768px;
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
}
@media (min-width: 992px) {
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
.custom-container {
max-width: 992px;
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
}
@media (min-width: 1200px) {
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
.custom-container {
max-width: 1200px;
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
}
`)
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test('plugins can check if corePlugins are enabled', () => {
let config = {
content: [{ raw: html`<div class="test"></div>` }],
plugins: [
function ({ addUtilities, corePlugins }) {
addUtilities({
'.test': {
'text-color': corePlugins('textColor') ? 'true' : 'false',
opacity: corePlugins('opacity') ? 'true' : 'false',
},
})
},
],
corePlugins: { textColor: false },
}
return run('@tailwind utilities', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
.test {
text-color: false;
opacity: true;
}
`)
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test('plugins can check if corePlugins are enabled when using array white-listing', () => {
let config = {
content: [{ raw: html`<div class="test"></div>` }],
plugins: [
function ({ addUtilities, corePlugins }) {
addUtilities({
'.test': {
'text-color': corePlugins('textColor') ? 'true' : 'false',
opacity: corePlugins('opacity') ? 'true' : 'false',
},
})
},
],
corePlugins: ['textColor'],
}
return run('@tailwind utilities', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
.test {
text-color: true;
opacity: false;
}
`)
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test('plugins can provide fallbacks to keys missing from the config', () => {
let config = {
content: [{ raw: html`<button class="btn"></button>` }],
plugins: [
function ({ addComponents, config }) {
addComponents({
'.btn': {
borderRadius: config('borderRadius.default', '.25rem'),
},
})
},
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
],
theme: {
borderRadius: {
1: '1px',
2: '2px',
4: '4px',
8: '8px',
},
},
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
return run('@tailwind components', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
.btn {
border-radius: 0.25rem;
}
`)
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test('plugins can add multiple sets of utilities and components', () => {
let config = {
content: [
{
raw: html`<button class="btn"></button>
<div class="card custom-skew-12deg custom-border-collapse"></div>`,
},
],
plugins: [
function ({ addUtilities, addComponents }) {
addComponents({
'.card': {
padding: '1rem',
borderRadius: '.25rem',
},
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
addUtilities({
'.custom-skew-12deg': {
transform: 'skewY(-12deg)',
},
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
addComponents({
'.btn': {
padding: '1rem .5rem',
display: 'inline-block',
},
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
addUtilities({
'.custom-border-collapse': {
borderCollapse: 'collapse',
},
})
},
],
}
return run('@tailwind components; @tailwind utilities;', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
.card {
border-radius: 0.25rem;
padding: 1rem;
}
.btn {
padding: 1rem 0.5rem;
display: inline-block;
}
.custom-skew-12deg {
transform: skewY(-12deg);
}
.custom-border-collapse {
border-collapse: collapse;
}
`)
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test('plugins respect prefix and important options by default when adding utilities', () => {
let config = {
prefix: 'tw-',
important: true,
content: [{ raw: html`<div class="tw-custom-rotate-90"></div>` }],
plugins: [
function ({ addUtilities }) {
addUtilities({
'.custom-rotate-90': {
transform: 'rotate(90deg)',
},
})
},
],
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
return run('@tailwind utilities', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
.tw-custom-rotate-90 {
transform: rotate(90deg) !important;
}
`)
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test('when important is a selector it is used to scope utilities instead of adding !important', () => {
let config = {
prefix: 'tw-',
important: '#app',
content: [{ raw: html`<div class="tw-custom-rotate-90"></div>` }],
plugins: [
function ({ addUtilities }) {
addUtilities({
'.custom-rotate-90': {
transform: 'rotate(90deg)',
},
})
},
],
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
return run('@tailwind utilities', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
#app .tw-custom-rotate-90 {
transform: rotate(90deg);
}
`)
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test('when important is a selector it scopes all selectors in a rule, even though defining utilities like this is stupid', () => {
let config = {
important: '#app',
content: [{ raw: html`<div class="custom-rotate-90 custom-rotate-1/4"></div>` }],
plugins: [
function ({ addUtilities }) {
addUtilities({
'.custom-rotate-90, .custom-rotate-1\\/4': {
transform: 'rotate(90deg)',
},
})
},
],
}
return run('@tailwind utilities', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
#app .custom-rotate-90,
#app .custom-rotate-1\/4 {
transform: rotate(90deg);
}
`)
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test('important utilities are not made double important when important option is used', () => {
let config = {
important: true,
content: [{ raw: html`<div class="custom-rotate-90"></div>` }],
plugins: [
function ({ addUtilities }) {
addUtilities({
'.custom-rotate-90': {
transform: 'rotate(90deg) !important',
},
})
},
],
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
return run('@tailwind utilities', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
.custom-rotate-90 {
transform: rotate(90deg) !important;
}
`)
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test("component declarations respect the 'prefix' option by default", () => {
let config = {
prefix: 'tw-',
content: [{ raw: html`<button class="tw-btn-blue"></button>` }],
plugins: [
function ({ addComponents }) {
addComponents({
'.btn-blue': {
backgroundColor: 'blue',
},
})
},
],
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
return run('@tailwind components', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
.tw-btn-blue {
background-color: #00f;
}
`)
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test('all selectors in a rule are prefixed', () => {
let config = {
prefix: 'tw-',
content: [
{
raw: html`<button class="tw-btn-blue tw-btn-red"></button>
<div class="tw-custom-rotate-90 tw-custom-rotate-1/4"></div>`,
},
],
plugins: [
function ({ addUtilities, addComponents }) {
addUtilities({
'.custom-rotate-90, .custom-rotate-1\\/4': {
transform: 'rotate(90deg)',
},
})
addComponents({
'.btn-blue, .btn-red': {
padding: '10px',
},
})
},
],
}
return run('@tailwind components', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
.tw-btn-blue,
.tw-btn-red {
padding: 10px;
}
`)
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test("component declarations can optionally ignore 'prefix' option", () => {
let config = {
prefix: 'tw-',
content: [{ raw: html`<button class="btn-blue"></button>` }],
plugins: [
function ({ addComponents }) {
addComponents(
{
'.btn-blue': {
backgroundColor: 'blue',
},
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
},
{ respectPrefix: false }
)
},
],
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
return run('@tailwind components', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
.btn-blue {
background-color: #00f;
}
`)
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test("component declarations are not affected by the 'important' option", () => {
let config = {
important: true,
content: [{ raw: html`<button class="btn-blue"></button>` }],
plugins: [
function ({ addComponents }) {
addComponents({
'.btn-blue': {
backgroundColor: 'blue',
},
})
},
],
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
return run('@tailwind components', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
.btn-blue {
background-color: #00f;
}
`)
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test("plugins can apply the user's chosen prefix to components manually", () => {
let config = {
prefix: 'tw-',
content: [{ raw: html`<button class="tw-btn-blue"></button>` }],
plugins: [
function ({ addComponents, prefix }) {
addComponents(
{
[prefix('.btn-blue')]: {
backgroundColor: 'blue',
},
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
},
{ respectPrefix: false }
)
},
],
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
return run('@tailwind components', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
.tw-btn-blue {
background-color: #00f;
}
`)
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test('prefix can optionally be ignored for utilities', () => {
let config = {
prefix: 'tw-',
content: [{ raw: html`<div class="custom-rotate-90"></div>` }],
plugins: [
function ({ addUtilities }) {
addUtilities(
{
'.custom-rotate-90': {
transform: 'rotate(90deg)',
},
},
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
{ respectPrefix: false }
)
},
],
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
return run('@tailwind utilities', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
.custom-rotate-90 {
transform: rotate(90deg);
}
`)
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test('important can optionally be ignored for utilities', () => {
let config = {
important: true,
content: [{ raw: html`<div class="custom-rotate-90"></div>` }],
plugins: [
function ({ addUtilities }) {
addUtilities(
{
'.custom-rotate-90': {
transform: 'rotate(90deg)',
},
},
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
{ respectImportant: false }
)
},
],
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
return run('@tailwind utilities', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
.custom-rotate-90 {
transform: rotate(90deg);
}
`)
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test('prefix will prefix all classes in a selector', () => {
let config = {
prefix: 'tw-',
content: [{ raw: html`<div class="tw-btn-blue tw-w-1/4"></div>` }],
plugins: [
function ({ addComponents, prefix }) {
addComponents(
{
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
[prefix('.btn-blue .w-1\\/4 > h1.text-xl + a .bar')]: {
backgroundColor: 'blue',
},
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
},
{ respectPrefix: false }
)
},
],
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
return run('@tailwind components', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
.tw-btn-blue .tw-w-1\/4 > h1.tw-text-xl + a .tw-bar {
background-color: #00f;
}
`)
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test('plugins can be provided as an object with a handler function', () => {
let config = {
content: [
{
raw: html`<div class="custom-object-fill custom-object-contain custom-object-cover"></div>`,
},
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
],
plugins: [
{
handler({ addUtilities }) {
addUtilities({
'.custom-object-fill': {
'object-fit': 'fill',
},
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
'.custom-object-contain': {
'object-fit': 'contain',
},
'.custom-object-cover': {
'object-fit': 'cover',
},
})
},
},
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
],
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
return run('@tailwind utilities', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
.custom-object-fill {
object-fit: fill;
}
.custom-object-contain {
object-fit: contain;
}
.custom-object-cover {
object-fit: cover;
}
`)
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test('plugins can provide a config but no handler', () => {
let config = {
content: [
{
raw: html`<div
class="tw-custom-object-fill tw-custom-object-contain tw-custom-object-cover"
></div>`,
},
],
plugins: [
{
config: {
prefix: 'tw-',
},
},
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
{
handler({ addUtilities }) {
addUtilities({
'.custom-object-fill': {
'object-fit': 'fill',
},
'.custom-object-contain': {
'object-fit': 'contain',
},
'.custom-object-cover': {
'object-fit': 'cover',
},
})
},
},
],
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
return run('@tailwind utilities', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
.tw-custom-object-fill {
object-fit: fill;
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
.tw-custom-object-contain {
object-fit: contain;
}
.tw-custom-object-cover {
object-fit: cover;
}
`)
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test('plugins can be created using the `createPlugin` function', () => {
let config = {
content: [{ raw: html`<div class="test-sm test-md test-lg hover:test-sm sm:test-sm"></div>` }],
corePlugins: [],
theme: {
screens: {
sm: '400px',
},
},
plugins: [
createPlugin(
function ({ addUtilities, theme }) {
addUtilities(
Object.fromEntries(
Object.entries(theme('testPlugin')).map(([k, v]) => [
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
`.test-${k}`,
{ testProperty: v },
])
)
)
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
},
{
theme: {
testPlugin: {
sm: '1rem',
md: '2rem',
lg: '3rem',
},
},
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
),
],
}
return run('@tailwind utilities', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
.test-sm {
test-property: 1rem;
}
.test-md {
test-property: 2rem;
}
.test-lg {
test-property: 3rem;
}
.hover\:test-sm:hover {
test-property: 1rem;
}
@media (min-width: 400px) {
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
.sm\:test-sm {
test-property: 1rem;
}
}
`)
})
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test('plugins with extra options can be created using the `createPlugin.withOptions` function', () => {
let plugin = createPlugin.withOptions(
function ({ className }) {
return function ({ addUtilities, theme }) {
addUtilities(
Object.fromEntries(
Object.entries(theme('testPlugin')).map(([k, v]) => [
`.${className}-${k}`,
{ testProperty: v },
])
)
)
}
},
function () {
return {
theme: {
testPlugin: {
sm: '1rem',
md: '2rem',
lg: '3rem',
},
},
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
}
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
)
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
let config = {
content: [
{
raw: html`<div class="banana-sm banana-md banana-lg hover:banana-sm sm:banana-sm"></div>`,
},
],
corePlugins: [],
theme: {
screens: {
sm: '400px',
},
},
plugins: [plugin({ className: 'banana' })],
}
return run('@tailwind utilities', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
.banana-sm {
test-property: 1rem;
}
.banana-md {
test-property: 2rem;
}
.banana-lg {
test-property: 3rem;
}
.hover\:banana-sm:hover {
test-property: 1rem;
}
@media (min-width: 400px) {
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
.sm\:banana-sm {
test-property: 1rem;
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
}
`)
})
})
test('plugins should cache correctly', () => {
let plugin = createPlugin.withOptions(({ className = 'banana' } = {}) => ({ addComponents }) => {
addComponents({ [`.${className}`]: { position: 'absolute' } })
})
let config = {
content: [{ raw: html`<div class="banana sm:banana apple sm:apple"></div>` }],
corePlugins: [],
theme: {
screens: {
sm: '400px',
},
},
}
function internalRun(options = {}) {
return run('@tailwind components', {
...config,
plugins: [plugin(options)],
})
}
return Promise.all([internalRun(), internalRun({ className: 'apple' })]).then(
([result1, result2]) => {
let expected1 = css`
.banana {
position: absolute;
}
@media (min-width: 400px) {
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
.sm\:banana {
position: absolute;
}
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
`
let expected2 = css`
.apple {
position: absolute;
}
@media (min-width: 400px) {
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
.sm\:apple {
position: absolute;
}
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
`
Bump `lightningcss` dependency (#11388) * bump `lightningcss` * allow for non-standard selector combinators such as `::deep` * just use Prettier when comparing CSS results We were using 2 different engines where the stable one was not using Lightning CSS and the Oxide one was using Lightning CSS. To ensure that we didn't have to rewrite every single test expectation, the `toMatchFormattedCss` parsed both the actual and expected value using Lightning CSS (to make the result similar), then it used Prettier to make it... pretty. Right now we _only_ use Lightning CSS, which means that we can drop the additional lightningcss format step and just use Prettier on both the actual and expected values. Pretty also only prettifies the CSS, it doesn't rewrite it. E.g.: `@media (min-width: 768px)` will not be optimized to `@media (width >= 768px)`, that's something that Lightning CSS does for us. This will require some changes in our test output, but it will be consistent afterwards because there won't be hidden transformation steps anymore. Because up until now it could be that the actual result was `color: black` but the tests showed `color: #000` (because it is shorter). This change will reflect reality. * update tests based on previous commit * only use `toMatchFormattedCss` instead of `toMatchCss` They both do the exact same thing right now. While `toMatchCss` is shorter, `toMatchFormattedCss` makes a bit more sense since we are comparing the Prettier results. * update integration tests
2023-06-07 15:56:32 +02:00
expect(result1.css).toMatchFormattedCss(expected1)
expect(result2.css).toMatchFormattedCss(expected2)
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
}
)
})
test('plugins created using `createPlugin.withOptions` do not need to be invoked if the user wants to use the default options', () => {
let plugin = createPlugin.withOptions(
function ({ className } = { className: 'banana' }) {
return function ({ addUtilities, theme }) {
addUtilities(
Object.fromEntries(
Object.entries(theme('testPlugin')).map(([k, v]) => [
`.${className}-${k}`,
{ testProperty: v },
])
)
)
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
},
function () {
return {
theme: {
testPlugin: {
sm: '1rem',
md: '2rem',
lg: '3rem',
},
},
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
}
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
)
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
let config = {
content: [
{
raw: html`<div class="banana-sm banana-md banana-lg hover:banana-sm sm:banana-sm"></div>`,
},
],
corePlugins: [],
theme: {
screens: {
sm: '400px',
},
},
plugins: [plugin],
}
return run('@tailwind utilities', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
.banana-sm {
test-property: 1rem;
}
.banana-md {
test-property: 2rem;
}
.banana-lg {
test-property: 3rem;
}
.hover\:banana-sm:hover {
test-property: 1rem;
}
@media (min-width: 400px) {
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
.sm\:banana-sm {
test-property: 1rem;
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
}
`)
})
})
test('the configFunction parameter is optional when using the `createPlugin.withOptions` function', () => {
let plugin = createPlugin.withOptions(function ({ className }) {
return function ({ addUtilities, theme }) {
addUtilities(
Object.fromEntries(
Object.entries(theme('testPlugin')).map(([k, v]) => [
`.${className}-${k}`,
{ testProperty: v },
])
)
)
}
})
let config = {
content: [
{
raw: html`<div class="banana-sm banana-md banana-lg hover:banana-sm sm:banana-sm"></div>`,
},
],
corePlugins: [],
theme: {
screens: {
sm: '400px',
},
testPlugin: {
sm: '1px',
md: '2px',
lg: '3px',
},
},
plugins: [plugin({ className: 'banana' })],
}
return run('@tailwind utilities', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
.banana-sm {
test-property: 1px;
}
.banana-md {
test-property: 2px;
}
.banana-lg {
test-property: 3px;
}
.hover\:banana-sm:hover {
test-property: 1px;
}
@media (min-width: 400px) {
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
.sm\:banana-sm {
test-property: 1px;
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
}
`)
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test('keyframes are not escaped', () => {
let config = {
content: [{ raw: html`<div class="foo-[abc] md:foo-[def]"></div>` }],
corePlugins: { preflight: false },
plugins: [
function ({ matchUtilities }) {
matchUtilities({
foo: (value) => {
return {
[`@keyframes ${value}`]: {
'25.001%': {
color: 'black',
},
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
},
animation: `${value} 1s infinite`,
}
},
})
},
],
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
return run('@tailwind utilities', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
@keyframes abc {
25.001% {
color: #000;
}
}
.foo-\[abc\] {
animation: 1s infinite abc;
}
@media (min-width: 768px) {
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
@keyframes def {
Improve `addVariant` API (#5809) * fix incorrect comment Probably messed this up in another PR, so just a bit of cleaning. * implement a formatVariantSelector function This will be used to eventually simplify the addVariant API. The idea is that it can take a list of strings that define a certain format. Then it squashes everything to a single format how you would expect it. E.g.: Input: - '&:hover' - '&:focus' - '.dark &' - ':merge(.group):hover &' - ':merge(.group):focus &' Output: - ':merge(.group):focus:hover .dark &:focus:hover' The API here is: - `&`, this means "The parent" or "The previous selector" (you can think of it like if you are using nested selectors) - `:merge(.group)`, this means insert a `.group` if it doesn't exist yet, but if it does exist already, then merge the new value with the old value. This allows us to merge group-focus, group-hover into a single `.group:focus:hover ...` * add new `format`, `withRule` and `wrap` API for addVariant * implement backwards compatibility This will ensure that the backwards compatibility for `modifySelectors` and direct mutations to the `container` will still work. We will try to capture the changes made to the `rule.selector`, we will also "backup" the existing selector. This allows us to diff the old and new selectors and determine what actually happened. Once we know this, we can restore the selector to the "old" selector and add the diffed string e.g.: `.foo &`, to the `collectedFormats` as if you called `format()` directly. This is a bunch of extra work, but it allows us to be backwards compatible. In the future we could also warn if you are using `modifySelectors`, but it is going to be a little bit tricky, because usually that's implemented by plugin authors and therefore you don't have direct control over this. Maybe we can figure out the plugin this is used in and change the warning somehow? * fix incorrect test This was clearly a bug, keyframes should not include escaped variants at all. The reason this is here in the first place is because the nodes in a keyframe are also "rule" nodes. * swap the order of pseudo states The current implementation had a strange side effect, that resulted in incorrect class definitions. When you are combining the `:hover` and `:focus` event, then there is no difference between `:hover:focus` and `:focus:hover`. However, when you use `:hover::file-selector-button` or `::file-selector-button:hover`, then there is a big difference. In the first place, you can hover over the full file input to apply changes to the `File selector button`. In the second scenario you have to hover over the `File selector button` itself to apply changes. You can think of it as function calls: - focus(hover(text-center)) What you would expect is something like this: `.focus\:hover\:text-center:hover:focus`, where `hover` is on the inside, and `focus` is on the outside. However in the current implementation this is implemented as `.focus\:hover\:text-cener:focus:hover` * add more variant tests for the new API * update parallel variants tests to make use of new API * implement core variants with new API * simplify/cleanup existing plugin utils We can get rid of this because we drastically simplified the new addVariant API. * add addVariant shorthand signature The current API looks like this: ```js addVariant('name', ({ format, wrap }) => { // Wrap in an atRule wrap(postcss.atRule({ name: 'media', params: '(prefers-reduced-motion: reduce)' })) // "Mutate" the selector, for example prepend `.dark` format('.dark &') }) ``` It is also pretty common to have this: ```js addVariant('name', ({ format }) => format('.dark &')) ``` So we simplified this to: ```js addVariant('name', '.dark &') ``` It is also pretty common to have this: ```js addVariant('name', ({ wrap }) => wrap(postcss.atRule({ name: 'media', params: '(prefers-reduced-motion: reduce)' }))) ``` So we simplified this to: ```js addVariant('name', '@media (prefers-reduced-motion: reduce)') ``` * improve fontVariantNumeric implementation We will use `@defaults`, so that only the resets are injected for the utilities we actually use. * fix typo * allow for nested addVariant shorthand This will allow to write something like: ```js addVariant('name', ` @supports (hover: hover) { @media (print) { &:hover } } `) // Or as a one-liner addVariant('name', '@supports (hover: hover) { @media (print) { &:hover } }') ``` * update changelog
2021-10-18 11:26:11 +02:00
25.001% {
color: #000;
}
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
.md\:foo-\[def\] {
animation: 1s infinite def;
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
}
`)
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test('font sizes are retrieved without default line-heights or letter-spacing using theme function', () => {
let config = {
content: [{ raw: html`<div class="foo"></div>` }],
corePlugins: [],
theme: {
fontSize: {
sm: ['14px', '20px'],
},
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
},
plugins: [
function ({ addComponents, theme }) {
addComponents({
'.foo': {
fontSize: theme('fontSize.sm'),
},
})
},
],
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
return run('@tailwind components', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
.foo {
font-size: 14px;
}
`)
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test('outlines are retrieved without outline-offset using theme function', () => {
let config = {
content: [{ raw: html`<div class="foo"></div>` }],
corePlugins: [],
theme: {
outline: {
black: ['2px dotted black', '4px'],
},
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
},
plugins: [
function ({ addComponents, theme }) {
addComponents({
'.foo': {
outline: theme('outline.black'),
},
})
},
],
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
return run('@tailwind components', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
.foo {
outline: 2px dotted #000;
}
`)
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test('box-shadow values are joined when retrieved using the theme function', () => {
let config = {
content: [{ raw: html`<div class="foo"></div>` }],
corePlugins: [],
theme: {
boxShadow: {
lol: ['width', 'height'],
},
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
},
plugins: [
function ({ addComponents, theme }) {
addComponents({
'.foo': {
boxShadow: theme('boxShadow.lol'),
},
})
},
],
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
return run('@tailwind components', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
.foo {
box-shadow: width, height;
}
`)
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test('transition-property values are joined when retrieved using the theme function', () => {
let config = {
content: [{ raw: html`<div class="foo"></div>` }],
corePlugins: [],
theme: {
transitionProperty: {
lol: ['width', 'height'],
},
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
},
plugins: [
function ({ addComponents, theme }) {
addComponents({
'.foo': {
transitionProperty: theme('transitionProperty.lol'),
},
})
},
],
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
return run('@tailwind components', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
.foo {
transition-property: width, height;
}
`)
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test('transition-duration values are joined when retrieved using the theme function', () => {
let config = {
content: [{ raw: html`<div class="foo"></div>` }],
corePlugins: [],
theme: {
transitionDuration: {
lol: ['width', 'height'],
},
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
},
plugins: [
function ({ addComponents, theme }) {
addComponents({
'.foo': {
transitionDuration: theme('transitionDuration.lol'),
},
})
},
],
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
return run('@tailwind components', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
.foo {
transition-duration: width, height;
}
`)
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test('transition-delay values are joined when retrieved using the theme function', () => {
let config = {
content: [{ raw: html`<div class="foo"></div>` }],
corePlugins: [],
theme: {
transitionDuration: {
lol: ['width', 'height'],
},
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
},
plugins: [
function ({ addComponents, theme }) {
addComponents({
'.foo': {
transitionDuration: theme('transitionDuration.lol'),
},
})
},
],
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
return run('@tailwind components', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
.foo {
transition-duration: width, height;
}
`)
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test('transition-timing-function values are joined when retrieved using the theme function', () => {
let config = {
content: [{ raw: html`<div class="foo"></div>` }],
corePlugins: [],
theme: {
transitionTimingFunction: {
lol: ['width', 'height'],
},
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
},
plugins: [
function ({ addComponents, theme }) {
addComponents({
'.foo': {
transitionTimingFunction: theme('transitionTimingFunction.lol'),
},
})
},
],
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
return run('@tailwind components', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
.foo {
transition-timing-function: width, height;
}
`)
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test('background-image values are joined when retrieved using the theme function', () => {
let config = {
content: [{ raw: html`<div class="foo"></div>` }],
corePlugins: [],
theme: {
backgroundImage: {
lol: ['width', 'height'],
},
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
},
plugins: [
function ({ addComponents, theme }) {
addComponents({
'.foo': {
backgroundImage: theme('backgroundImage.lol'),
},
})
},
],
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
return run('@tailwind components', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
.foo {
background-image: width, height;
}
`)
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test('background-size values are joined when retrieved using the theme function', () => {
let config = {
content: [{ raw: html`<div class="foo"></div>` }],
corePlugins: [],
theme: {
backgroundSize: {
lol: ['width', 'height'],
},
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
},
plugins: [
function ({ addComponents, theme }) {
addComponents({
'.foo': {
backgroundSize: theme('backgroundSize.lol'),
},
})
},
],
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
return run('@tailwind components', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
.foo {
background-size: width, height;
}
`)
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test('background-color values are joined when retrieved using the theme function', () => {
let config = {
content: [{ raw: html`<div class="foo"></div>` }],
corePlugins: [],
theme: {
backgroundColor: {
lol: ['width', 'height'],
},
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
},
plugins: [
function ({ addComponents, theme }) {
addComponents({
'.foo': {
backgroundColor: theme('backgroundColor.lol'),
},
})
},
],
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
return run('@tailwind components', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
.foo {
background-color: width, height;
}
`)
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test('cursor values are joined when retrieved using the theme function', () => {
let config = {
content: [{ raw: html`<div class="foo"></div>` }],
corePlugins: [],
theme: {
cursor: {
lol: ['width', 'height'],
},
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
},
plugins: [
function ({ addComponents, theme }) {
addComponents({
'.foo': {
cursor: theme('cursor.lol'),
},
})
},
],
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
return run('@tailwind components', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
.foo {
cursor: width, height;
}
`)
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test('animation values are joined when retrieved using the theme function', () => {
let config = {
content: [{ raw: html`<div class="foo"></div>` }],
corePlugins: [],
theme: {
animation: {
lol: ['width', 'height'],
},
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
},
plugins: [
function ({ addComponents, theme }) {
addComponents({
'.foo': {
animation: theme('animation.lol'),
},
})
},
],
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
return run('@tailwind components', config).then((result) => {
expect(result.css).toMatchFormattedCss(css`
.foo {
animation: width, height;
}
`)
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
})
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
test('custom properties are not converted to kebab-case when added to base layer', () => {
let config = {
content: [],
plugins: [
function ({ addBase }) {
addBase({
':root': {
'--colors-primaryThing-500': '0, 0, 255',
},
})
},
],
}
Merge engines (#11275) * Simplify CI, make oxide engine the default (#11281) * remove integration tests for the `stable` engine * make `integration-tests-oxide` the default integration tests workflow * remove unnecessary CACHE_PREFIX * drop `ci-stable.yml` workflow * make `CI — Oxide` the default + drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX * drop `release-insiders-stable.yml` workflow * make `Release Insiders — Oxide` the default + change release channel to just `insiders` instead of `oxide-insders` * drop 3.3 branch from integration tests * change job name for insiders release This makes it consistent with the other job names * prep `release-oxide.yml` workflow to be the default workflow * add Tailwind Play update Currently commented out until we figure out how this will work exactly. * use `env.VERSION` for the version we want to release * drop `release-stable.yml` workflow * make `release-oxide.yml` the default `release.yml` workflow * inline "Calculate environment variables" step * cache node_modules and cargo related files/folders in the release step * always use the default CLI * drop oxide specific implementation * ensure we test `--postcss` in the CLI Even for the Oxide engine * always process `@import` rules * remove `generalizedModifiers` flag This was already enabled by default. This commits removes some of the outstanding references to it. * remove built-in peer dependencies for the CLI * drop unused esbuild dependency * fix type for `configBag` * setup Lightning CSS for the CLI * drop `cssnano` dependency We only used this in the CLI and we now use Lighting CSS which has this built in already. Therefore we can get rid of this as a dependency. * ensure `imported.css` file exists in integration tests * passthrough `options` to lightningcss Ideally we can read this from `result.map` instead. However this doesn't get filled in for whatever reason even though we use `map: {inline:true}`. You can run the `tests/cli.test.js`, and more specifically the `--postcss supports process options with custom config` test. * Always process CSS with Lightning CSS Some tests temporarily skipped. Autoprefixer removed from `postcss.config.js` stubs since vendor prefixing handled by Lightning. * Remove code for normalizing `@import "tailwindcss/*"` statements * ensure tailwind doesn't crash when a `tailwind.config.js` file is not present * add `log.group` to group multiple messages together with different types * remove engine specific checks in integration tests * remove unused imports/variables Make linting check happy * support `content: ['auto']` This will allow us to still use auto content detection, but since this is part of the `content` array, it also allows you to add custom paths if you want. E.g.: ```js content: ['auto', './node_modules/my-library/*.{jsx,tsx}'] ``` * ensure `content.files` is always an array This allows us to simplify some checks because 'auto' will now be part of the array instead of checking if `content.files` is auto or if it is an array containing 'auto'. * fix tests, ensure default config is not injected * simplify `auto` normalization * always use the defaultFullConfig No need to override the defaultFullConfig with `{content: 'auto'}` because this will be included in the default config already. * drop condition which ensured `files` was an empty array This is not needed anymore because when `content` is omitted it behaves as if it was set to `auto`. * drop removal of `content` We used to remove the `content` from the actual configuration files when using `tailwindcss init` for the oxide engine. This was to ensure that `auto content detection` was used instead (by default). But now it is always enabled by default therefore this is not needed anymore. * ensure setting `content: 'auto'` works * improve file cache handling We have to make sure that we get into the previous state whenver a test is done. We were using some `!fileCache[filePath]` checks, however we also used `null` as a sentinel value when something wasn't found. But, `null` is falsey as well so some checks where incorrect. Using a dedicated value and a `Map` makes this safer and more correct because we can now use `.has()`. * drop `cleanupFile`, `removeFile` will already take care of it * drop oxide check in `resolvedChangedContent` At this point the `context.tailwindConfig.content.files` is already fully resolved regardless of the engine we are in. * refactor `parseCandidateStringsFromFiles` strategy, to make use of a proper feature flag * use feature flag for sorting classes Once the Oxide engine is the default default, then we can drop this entirely because the result from the Rust parser will already be sorted. * drop `crosscheck` from tests where it is safe First pass of deleting `crosscheck`. These are all the places where we didn't have any differences between the Oxide and Stable engine. * replace `__OXIDE__` in corePlugins with feature flag * use `globalThis.__OXIDE__ ?? false` This will ensure that in places where we don't have `__OXIDE__` that we can still properly fallback to `false`. * use `flex` as the go-to utility when testing features * prefer `space-utilities` tests instead of `oxide` test * drop crosscheck check Since the `oxideParser` is disabled by default, all the tests can use the `stable` output. * use simple `false` default values for feature flag defaults * drop `__OXIDE__` injections in build scripts * use stable `flex` and `z-{...}` utilities instead of color utilities flex and z-index related utilities are more stable than the color utilities right now because the color utilities will use a raw color value or a combination with a css variable depending on a feature flag. * drop unused `ENGINE` environment variable * drop stable engine manifest files * drop `swap-engines` tooling --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2023-05-25 04:10:00 +02:00
return run('@tailwind base', config).then((result) => {
expect(result.css).toContain(`--colors-primaryThing-500: 0, 0, 255;`)
})
})
test('plugins can loaded by package name / path', async () => {
let config = {
content: [{ raw: 'example-1' }],
plugins: [`${__dirname}/fixtures/plugins/example.cjs`],
}
let result = await run('@tailwind utilities', config)
expect(result.css).toMatchFormattedCss(css`
.example-1 {
color: red;
}
`)
})
test('named plugins can specify options', async () => {
let config = {
content: [{ raw: 'ex-example-1 example-1' }],
plugins: [[`${__dirname}/fixtures/plugins/example.cjs`, { prefix: 'ex-' }]],
}
let result = await run('@tailwind utilities', config)
expect(result.css).toMatchFormattedCss(css`
.ex-example-1 {
color: red;
}
`)
})
test('named plugins resolve default export', async () => {
let config = {
content: [{ raw: 'example-1' }],
plugins: [`${__dirname}/fixtures/plugins/example.default.cjs`],
}
let result = await run('@tailwind utilities', config)
expect(result.css).toMatchFormattedCss(css`
.example-1 {
color: red;
}
`)
})
test('named plugins resolve default export when using options', async () => {
let config = {
content: [{ raw: 'example-1 ex-example-1' }],
plugins: [[`${__dirname}/fixtures/plugins/example.default.cjs`, { prefix: 'ex-' }]],
}
let result = await run('@tailwind utilities', config)
expect(result.css).toMatchFormattedCss(css`
.ex-example-1 {
color: red;
}
`)
})