tailwindcss/integrations/tailwindcss-cli/tests/cli.test.js

655 lines
18 KiB
JavaScript
Raw Normal View History

let path = require('path')
let $ = require('../../execute')
let { css, html, javascript } = require('../../syntax')
let resolveToolRoot = require('../../resolve-tool-root')
let version = require('../../../package.json').version
let {
cleanupFile,
fileExists,
readOutputFile,
removeFile,
waitForOutputFileCreation,
writeInputFile,
} = require('../../io')({
output: 'dist',
input: 'src',
})
let EXECUTABLE = 'node ../../lib/cli.js'
function dedent(input) {
let lines = input.split('\n')
let minIndent = lines.reduce(
(min, line) => Math.min(min, line.trim() === '' ? Infinity : line.match(/^\s*/)[0].length),
Infinity
)
return lines
.map((line) => line.slice(minIndent))
.join('\n')
.trim()
}
describe('Build command', () => {
test('--output', async () => {
await writeInputFile('index.html', html`<div class="font-bold shadow"></div>`)
await $(`${EXECUTABLE} --output ./dist/main.css`)
let contents = await readOutputFile('main.css')
// `-i` is omitted, therefore the default `@tailwind base; @tailwind
// components; @tailwind utilities` is used. However `preflight` is
// disabled. I still want to verify that the `base` got included.
Enable optimize universal defaults by default (#5635) * enabled `optimizeUniversalDefaults` by default This PR is done in a way so that the default is set to `true`, but you can still disable it if it causes issues. In this case we do appreciate an issue in that case 😅. * update tests to use optimized universal selector * update integration tests * add dedicated tests for the optimized universal selector * improve minimumImpactSelector algorithm I think I cracked the algorithm, but I will probably need another pair of eyes on the subject. The current implementation works like this: Prerequisites: - The selector should already have been parsed using the selectorParser from 'postcss-selector-parser'. Algorithm: 1. Remove all of the pseudo classes from the list of nodes. 1.1. We do want to keep pseudo elements (E.g.: `::before`, `::first-line`, ...) 1.2. We do want to keep pseudo classes that contain nodes (E.g.: `:not(...)`) 2. Reverse the list of nodes. This will make it easier to search from the end to the start. For example `.group:hover .group-hover` should result in `.group-hover` not `.group`. 2.1. Find the index of the best match (class, id, attribute), and convert the node if required. (E.g.: `span#app` -> `#app` => `[id="app"]`) 2.2. Remove the rest of the selector that is not important anymore 2.3. Re-join the left-over nodes together * update tests using new algorithm * also look for `tag` types * take `tag` into account * simplify logic * add test to prove `rest.reverse()` in first case is required In case we don't find a match (idx === -1), we use `rest.reverse()`. However, it looks like you can just use `nodes` instead. This is not entirely true, because the `rest` variable will contain only the nodes that are not pseudo elements. `*:hover` would result in `*:hover` instead of just `*` * replace all nodes after > with a single universal selector
2021-10-06 17:45:26 +02:00
expect(contents).toContain('--tw-ring-offset-shadow: 0 0 #0000')
expect(contents).toContain('--tw-ring-shadow: 0 0 #0000')
expect(contents).toContain('--tw-shadow: 0 0 #0000')
// Verify `utilities` output is correct
expect(contents).toIncludeCss(
css`
.font-bold {
font-weight: 700;
}
`
)
})
test('--input, --output', async () => {
await writeInputFile('index.html', html`<div class="font-bold"></div>`)
await $(`${EXECUTABLE} --input ./src/index.css --output ./dist/main.css`)
expect(await readOutputFile('main.css')).toIncludeCss(
css`
.font-bold {
font-weight: 700;
}
`
)
})
test('--minify', async () => {
await writeInputFile('index.html', html`<div class="font-bold"></div>`)
await $(`${EXECUTABLE} --output ./dist/main.css --minify`)
let withMinify = await readOutputFile('main.css')
// Verify that we got the expected output. Note: `.toIncludeCss` formats
// `actual` & `expected`
expect(withMinify).toIncludeCss(
css`
.font-bold {
font-weight: 700;
}
`
)
await $(`${EXECUTABLE} --output ./dist/main.css`)
let withoutMinify = await readOutputFile('main.css')
// Let's verify that the actual minified output is smaller than the not
// minified version.
expect(withoutMinify.length).toBeGreaterThan(withMinify.length)
})
// Deprecated
test('--no-autoprefixer (should produce a warning)', async () => {
await writeInputFile('index.html', html`<div class="select-none"></div>`)
await writeInputFile(
'index.css',
css`
@tailwind utilities;
`
)
let runningProcess = $(
`${EXECUTABLE} --input ./src/index.css --output ./dist/main.css --no-autoprefixer`
)
let warning = runningProcess.onStderr((message) => message.includes('--no-autoprefixer'))
await runningProcess
expect(await warning).toMatchInlineSnapshot(`
"[deprecation] The --no-autoprefixer flag is deprecated and has no effect.
"
`)
let withoutAutoprefixer = await readOutputFile('main.css')
// This contains --webkit-user-select which may be strange, but it is expected because we are
// not handling the `--no-autoprefixer` flag anymore at all.
expect(withoutAutoprefixer).toMatchInlineSnapshot(`
"/* ! tailwindcss v3.3.2 | MIT License | https://tailwindcss.com */
.select-none {
-webkit-user-select: none;
user-select: none;
}
"
`)
})
test('--config (non-existing config file)', async () => {
await writeInputFile('index.html', html`<div class="font-bold"></div>`)
let { stderr } = await $(
`${EXECUTABLE} --output ./dist/main.css --config ./non-existing.config.js`
).catch((err) => err)
let toolRoot = resolveToolRoot()
expect(stderr).toEqual(
`Specified config file ${path.resolve(toolRoot, 'non-existing.config.js')} does not exist.\n`
)
})
test('--config (existing config file)', async () => {
await writeInputFile('index.html', html`<div class="font-bold"></div>`)
let customConfig = `module.exports = ${JSON.stringify(
{
Remove AOT (#5340) * make `jit` mode the default when no mode is specified * unify JIT and AOT codepaths * ensure `Object.entries` on undefined doesn't break It could be that sometimes you don't have values in your config (e.g.: `presets: []`), this in turn will break some plugins where we assume we have a value. * drop AOT specific tests These tests are all covered by JIT mode already and were AOT specific. * simplify tests, and add a few Some of the tests were written for AOT specifically, some were missing. We also updated the way we write those tests, essentially making Tailwind a blackbox, by testing against the final output. Now that JIT mode is the default, this is super fast because we only generate what is used, instead of partially testing in a 3MB file or building it all, then purging. * add some todo's to make sure we warn in a few cases * make `darkMode: 'media'`, the default This also includes moving dark mode tests to its own dedicated file. * remove PostCSS 7 compat mode * update CLI to be JIT-first * fix integration tests This is not a _real_ fix, but it does solve the broken test for now. * warn when using @responsive or @variants * remove the JIT preview warning * remove AOT-only code paths * remove all `mode: 'jit'` blocks Also remove `variants: {}` since they are not useful in `JIT` mode anymore. * drop unused dependencies * rename `purge` to `content` * remove static CDN builds * mark `--purge` as deprecated in the CLI This will still work, but a warning will be printed and it won't show up in the `--help` output. * cleanup nesting plugin We don't have to duplicate it anymore since there is no PostCSS 7 version anymore. * make sure integration tests run in band * cleanup folder structure * make sure nesting folder is available * simplify resolving of purge/content information
2021-09-01 17:13:59 +02:00
content: ['./src/index.html'],
theme: {
extend: {
fontWeight: {
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
bold: 'bold',
},
},
},
corePlugins: {
preflight: false,
},
plugins: [],
},
null,
2
)}`
await writeInputFile('../custom.config.js', customConfig)
await $(`${EXECUTABLE} --output ./dist/main.css --config ./custom.config.js`)
expect(await readOutputFile('main.css')).toIncludeCss(
css`
.font-bold {
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
font-weight: bold;
}
`
)
})
test('--content', async () => {
await writeInputFile('other.html', html`<div class="font-bold"></div>`)
await $(`${EXECUTABLE} --content ./src/other.html --output ./dist/main.css`)
expect(await readOutputFile('main.css')).toIncludeCss(
css`
.font-bold {
font-weight: 700;
}
`
)
})
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('--postcss (postcss.config.js)', async () => {
await writeInputFile('index.html', html`<div class="font-bold"></div>`)
let customConfig = javascript`
let path = require('path')
let postcss = require('postcss')
module.exports = {
plugins: [
function before(root, result) {
// Inject a custom component with @apply rules to prove that we run
// this _before_ the actual tailwind 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
let btn = postcss.parse('.btn { @apply flex px-2 py-1 }')
root.append(btn.nodes)
},
function tailwindcss() {
return require(path.resolve('..', '..'))
},
function after(root, result) {
// Add '-after' to all the selectors
root.walkRules(rule => {
if (!rule.selector.startsWith('.')) return
rule.selector = rule.selector + '-after'
})
},
],
}
`
await writeInputFile('../postcss.config.js', customConfig)
await $(`${EXECUTABLE} --output ./dist/main.css --postcss`)
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
expect(await readOutputFile('main.css')).toIncludeCss(
css`
.font-bold-after {
font-weight: 700;
}
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-after {
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
padding: 0.25rem 0.5rem;
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
display: flex;
}
`
)
})
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('--postcss (custom.postcss.config.js)', async () => {
await writeInputFile('index.html', html`<div class="font-bold"></div>`)
let customConfig = javascript`
let path = require('path')
let postcss = require('postcss')
module.exports = {
plugins: [
function before(root, result) {
// Inject a custom component with @apply rules to prove that we run
// this _before_ the actual tailwind 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
let btn = postcss.parse('.btn { @apply flex px-2 py-1 }')
root.append(btn.nodes)
},
function tailwindcss() {
return require(path.resolve('..', '..'))
},
function after(root, result) {
// Add '-after' to all the selectors
root.walkRules(rule => {
if (!rule.selector.startsWith('.')) return
rule.selector = rule.selector + '-after'
})
},
],
}
`
await writeInputFile('../custom.postcss.config.js', customConfig)
await $(`${EXECUTABLE} --output ./dist/main.css --postcss ./custom.postcss.config.js`)
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
expect(await readOutputFile('main.css')).toIncludeCss(
css`
.font-bold-after {
font-weight: 700;
}
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-after {
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
padding: 0.25rem 0.5rem;
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
display: flex;
}
`
)
})
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('--postcss supports process options', async () => {
await writeInputFile('index.html', html`<div class="font-bold"></div>`)
let customConfig = javascript`
let path = require('path')
let postcss = require('postcss')
module.exports = {
map: { inline: true },
plugins: [
function tailwindcss() {
return require(path.resolve('..', '..'))
},
],
}
`
await writeInputFile('../postcss.config.js', customConfig)
await $(`${EXECUTABLE} --output ./dist/main.css --postcss`)
let contents = await readOutputFile('main.css')
expect(contents).toIncludeCss(
css`
.font-bold {
font-weight: 700;
}
`
)
expect(contents).toContain(`/*# sourceMappingURL`)
})
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('--postcss supports process options with custom config', async () => {
await writeInputFile('index.html', html`<div class="font-bold"></div>`)
let customConfig = javascript`
let path = require('path')
let postcss = require('postcss')
module.exports = {
map: { inline: true },
plugins: [
function tailwindcss() {
return require(path.resolve('..', '..'))
},
],
}
`
await writeInputFile('../custom.postcss.config.js', customConfig)
await $(`${EXECUTABLE} --output ./dist/main.css --postcss ./custom.postcss.config.js`)
let contents = await readOutputFile('main.css')
expect(contents).toIncludeCss(
css`
.font-bold {
font-weight: 700;
}
`
)
expect(contents).toContain(`/*# sourceMappingURL`)
})
test('postcss-import is supported by default', async () => {
cleanupFile('src/test.css')
await writeInputFile('index.html', html`<div class="md:something-cool"></div>`)
await writeInputFile(
'test.css',
css`
@import 'tailwindcss/base';
@import 'tailwindcss/components';
@import 'tailwindcss/utilities';
@import './imported.css';
`
)
await $(
`${EXECUTABLE} --input ./src/test.css --content ./src/index.html --output ./dist/main.css`
)
expect(await readOutputFile('main.css')).toIncludeCss(
css`
@media (min-width: 768px) {
.md\:something-cool {
color: red;
}
}
`
)
})
test('postcss-import is supported by default in watch mode', async () => {
cleanupFile('src/test.css')
await writeInputFile('index.html', html`<div class="md:something-cool"></div>`)
await writeInputFile(
'test.css',
css`
@import 'tailwindcss/base';
@import 'tailwindcss/components';
@import 'tailwindcss/utilities';
@import './imported.css';
`
)
let runningProcess = $(
`${EXECUTABLE} --watch --input ./src/test.css --content ./src/index.html --output ./dist/main.css`
)
await waitForOutputFileCreation('main.css')
expect(await readOutputFile('main.css')).toIncludeCss(
css`
@media (min-width: 768px) {
.md\:something-cool {
color: red;
}
}
`
)
await writeInputFile(
'imported.css',
css`
@layer utilities {
.something-cool {
color: blue;
}
}
`
)
await runningProcess.onStderr(function ready(message) {
return message.includes('Done in')
})
expect(await readOutputFile('main.css')).toIncludeCss(
css`
@media (min-width: 768px) {
.md\:something-cool {
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
color: #00f;
}
}
`
)
return runningProcess.stop()
})
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('postcss-import is included when using a custom postcss configuration', async () => {
cleanupFile('src/test.css')
await writeInputFile('index.html', html`<div class="md:something-cool"></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
await writeInputFile(
'imported.css',
css`
.foo {
color: white;
}
`
)
await writeInputFile(
'test.css',
css`
@import 'tailwindcss/base';
@import 'tailwindcss/components';
@import 'tailwindcss/utilities';
@import './imported.css';
`
)
await $(
`${EXECUTABLE} --input ./src/test.css --content ./src/index.html --output ./dist/main.css --postcss`
)
expect(await readOutputFile('main.css')).toIncludeCss(
css`
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
.foo {
color: #fff;
}
`
)
})
test('--help', async () => {
let { combined } = await $(`${EXECUTABLE} --help`)
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
expect(dedent(combined)).toEqual(
dedent(`
tailwindcss v${version}
Usage:
tailwindcss build [options]
Options:
-i, --input Input file
-o, --output Output file
-w, --watch Watch for changes and rebuild as needed
-p, --poll Use polling instead of filesystem events when watching
--content Content paths to use for removing unused classes
--postcss Load custom PostCSS configuration
-m, --minify Minify the output
-c, --config Path to a custom config file
-h, --help Display usage information
`)
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
)
})
})
describe('Init command', () => {
Enable ESM and TS based config files (#10785) * add `jiti` and `detective-typescript` dependencies * use `jiti` and `detective-typescript` Instead of `detective`, this way we will be able to support `tailwind.config.ts` files and `ESM` files. * use `@swc/core` instead of the built-in `babel` form `jiti` * update changelog * add `jiti` and `detective-typescript` dependencies to `stable` * use `sucrase` to transform the configs * add `sucrase` dependency to `stable` engine * make loading the config easier * use abstracted loading config utils * WIP: make `load` related files public API * use new config loader in PostCSS plugin * add list of default config files to look for * cleanup unused arguments * find default config path when using CLI * improve `init` command * make eslint happy * keep all files in `stubs` folder * add `tailwind.config.js` stub file * Initialize PostCSS config using the same format as Tailwind config * Rename config content stubs to config.*.js * Improve option descriptions for init options * Remove unused code, remove `constants` file * Fix TS warning * apply CLI changes to the Oxide version * update `--help` output in CLI tests * WIP: make tests work on CI TODO: Test all combinations of `--full`, `--ts`, `--postcss`, and `--esm`. * wip * remove unused `fs` * Fix init tests Did you know you could pass an empty args to a command? No? Me neither. ¯\_(ツ)_/¯ * bump `napi-derive` * list extensions we are interested in * no-op the `removeFile` if file doesn't exist * ensure all `init` flags work * ensure we cleanup the new files * test ESM/CJS generation based on package.json * remove unnecessary test We are not displaying output in the `--help` anymore based on whether `type: module` is present or not. Therefore this test is unneeded. * only look for `TypeScript` files when the entryFile is `TypeScript` as well * refactor `load` to be `loadConfig` This will allow you to use: ```js import loadConfig from 'tailwindcss/loadConfig' let config = loadConfig("/Users/xyz/projects/my-app/tailwind.config.ts") ``` The `loadConfig` function will return the configuration object based on the given absolute path of a tailwind configuration file. The given path can be a CJS, an ESM or a TS file. * use the `config.full.js` stub instead of the `defaultConfig.stub.js` file The root `defaultConfig` is still there for backwards compatibilty reasons. But the `module.exports = requrie('./config.full.js')` was causing some problems when actually using tailwindcss. So dropped it instead. * apply `load` -> `loadConfig` changes to `Oxide` engine CLI * ensure we write the config file in the Oxide engine * improve type in Oxide engine CLI * catch errors instead of checking if the file exists A little smaller but just for tests so doesn't matter too much here 👍 * ensure we publish the correct stub files --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com> Co-authored-by: Jordan Pittman <jordan@cryptica.me> Co-authored-by: Nate Moore <nate@natemoo.re> Co-authored-by: Enzo Innocenzi <enzo@innocenzi.dev>
2023-03-15 22:04:18 +01:00
it.each([
{ flags: [], name: 'tailwind.config.js' },
{ flags: ['--ts'], name: 'tailwind.config.ts' },
{ flags: ['--esm'], name: 'tailwind.config.js' },
{ flags: ['--full'], name: 'tailwind.config.js' },
{ flags: ['--ts', '--full'], name: 'tailwind.config.ts' },
{ flags: ['--esm', '--full'], name: 'tailwind.config.js' },
])('works with all these flags: %j', async ({ flags, name }) => {
await removeFile(name)
let { combined } = await $(`${EXECUTABLE} init ${flags.join(' ')}`)
expect(combined).toMatchInlineSnapshot(`
"
Created Tailwind CSS config file: ${name}
"
`)
expect(await fileExists(name)).toBe(true)
let content = await readOutputFile(`../${name}`)
if (flags.includes('--ts') || flags.includes('--esm')) {
expect(content).toContain('export default')
expect(content).not.toContain('module.exports =')
} else {
expect(content).toContain('module.exports =')
expect(content).not.toContain('export default')
}
if (flags.includes('--ts')) {
expect(content).toContain('satisfies Config')
}
if (flags.includes('--full')) {
expect(content.split('\n').length).toBeGreaterThan(50)
}
})
test('--full', async () => {
cleanupFile('full.config.js')
let { combined } = await $(`${EXECUTABLE} init full.config.js --full`)
expect(combined).toMatchInlineSnapshot(`
"
Created Tailwind CSS config file: full.config.js
"
`)
// Not a clean way to test this. We could require the file and verify that
// multiple keys in `theme` exists. However it loads `tailwindcss/colors`
// which doesn't exists in this context.
expect((await readOutputFile('../full.config.js')).split('\n').length).toBeGreaterThan(50)
})
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('--postcss', async () => {
expect(await fileExists('postcss.config.js')).toBe(true)
await removeFile('postcss.config.js')
expect(await fileExists('postcss.config.js')).toBe(false)
let { combined } = await $(`${EXECUTABLE} init --postcss`)
expect(await fileExists('postcss.config.js')).toBe(true)
expect(combined).toMatchInlineSnapshot(`
"
tailwind.config.js already exists.
Created PostCSS config file: postcss.config.js
"
`)
})
test('--help', async () => {
let { combined } = await $(`${EXECUTABLE} init --help`)
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
expect(dedent(combined)).toEqual(
dedent(`
tailwindcss v${version}
Usage:
tailwindcss init [options]
Options:
--esm Initialize configuration file as ESM
--ts Initialize configuration file as TypeScript
-p, --postcss Initialize a \`postcss.config.js\` file
-f, --full Include the default values for all options in the generated configuration file
-h, --help Display usage information
`)
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
)
})
Enable ESM and TS based config files (#10785) * add `jiti` and `detective-typescript` dependencies * use `jiti` and `detective-typescript` Instead of `detective`, this way we will be able to support `tailwind.config.ts` files and `ESM` files. * use `@swc/core` instead of the built-in `babel` form `jiti` * update changelog * add `jiti` and `detective-typescript` dependencies to `stable` * use `sucrase` to transform the configs * add `sucrase` dependency to `stable` engine * make loading the config easier * use abstracted loading config utils * WIP: make `load` related files public API * use new config loader in PostCSS plugin * add list of default config files to look for * cleanup unused arguments * find default config path when using CLI * improve `init` command * make eslint happy * keep all files in `stubs` folder * add `tailwind.config.js` stub file * Initialize PostCSS config using the same format as Tailwind config * Rename config content stubs to config.*.js * Improve option descriptions for init options * Remove unused code, remove `constants` file * Fix TS warning * apply CLI changes to the Oxide version * update `--help` output in CLI tests * WIP: make tests work on CI TODO: Test all combinations of `--full`, `--ts`, `--postcss`, and `--esm`. * wip * remove unused `fs` * Fix init tests Did you know you could pass an empty args to a command? No? Me neither. ¯\_(ツ)_/¯ * bump `napi-derive` * list extensions we are interested in * no-op the `removeFile` if file doesn't exist * ensure all `init` flags work * ensure we cleanup the new files * test ESM/CJS generation based on package.json * remove unnecessary test We are not displaying output in the `--help` anymore based on whether `type: module` is present or not. Therefore this test is unneeded. * only look for `TypeScript` files when the entryFile is `TypeScript` as well * refactor `load` to be `loadConfig` This will allow you to use: ```js import loadConfig from 'tailwindcss/loadConfig' let config = loadConfig("/Users/xyz/projects/my-app/tailwind.config.ts") ``` The `loadConfig` function will return the configuration object based on the given absolute path of a tailwind configuration file. The given path can be a CJS, an ESM or a TS file. * use the `config.full.js` stub instead of the `defaultConfig.stub.js` file The root `defaultConfig` is still there for backwards compatibilty reasons. But the `module.exports = requrie('./config.full.js')` was causing some problems when actually using tailwindcss. So dropped it instead. * apply `load` -> `loadConfig` changes to `Oxide` engine CLI * ensure we write the config file in the Oxide engine * improve type in Oxide engine CLI * catch errors instead of checking if the file exists A little smaller but just for tests so doesn't matter too much here 👍 * ensure we publish the correct stub files --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com> Co-authored-by: Jordan Pittman <jordan@cryptica.me> Co-authored-by: Nate Moore <nate@natemoo.re> Co-authored-by: Enzo Innocenzi <enzo@innocenzi.dev>
2023-03-15 22:04:18 +01:00
test('ESM config is created by default in an ESM project', async () => {
await removeFile('tailwind.config.js')
let pkg = await readOutputFile('../package.json')
await writeInputFile(
'../package.json',
JSON.stringify({
...JSON.parse(pkg),
type: 'module',
})
)
Enable ESM and TS based config files (#10785) * add `jiti` and `detective-typescript` dependencies * use `jiti` and `detective-typescript` Instead of `detective`, this way we will be able to support `tailwind.config.ts` files and `ESM` files. * use `@swc/core` instead of the built-in `babel` form `jiti` * update changelog * add `jiti` and `detective-typescript` dependencies to `stable` * use `sucrase` to transform the configs * add `sucrase` dependency to `stable` engine * make loading the config easier * use abstracted loading config utils * WIP: make `load` related files public API * use new config loader in PostCSS plugin * add list of default config files to look for * cleanup unused arguments * find default config path when using CLI * improve `init` command * make eslint happy * keep all files in `stubs` folder * add `tailwind.config.js` stub file * Initialize PostCSS config using the same format as Tailwind config * Rename config content stubs to config.*.js * Improve option descriptions for init options * Remove unused code, remove `constants` file * Fix TS warning * apply CLI changes to the Oxide version * update `--help` output in CLI tests * WIP: make tests work on CI TODO: Test all combinations of `--full`, `--ts`, `--postcss`, and `--esm`. * wip * remove unused `fs` * Fix init tests Did you know you could pass an empty args to a command? No? Me neither. ¯\_(ツ)_/¯ * bump `napi-derive` * list extensions we are interested in * no-op the `removeFile` if file doesn't exist * ensure all `init` flags work * ensure we cleanup the new files * test ESM/CJS generation based on package.json * remove unnecessary test We are not displaying output in the `--help` anymore based on whether `type: module` is present or not. Therefore this test is unneeded. * only look for `TypeScript` files when the entryFile is `TypeScript` as well * refactor `load` to be `loadConfig` This will allow you to use: ```js import loadConfig from 'tailwindcss/loadConfig' let config = loadConfig("/Users/xyz/projects/my-app/tailwind.config.ts") ``` The `loadConfig` function will return the configuration object based on the given absolute path of a tailwind configuration file. The given path can be a CJS, an ESM or a TS file. * use the `config.full.js` stub instead of the `defaultConfig.stub.js` file The root `defaultConfig` is still there for backwards compatibilty reasons. But the `module.exports = requrie('./config.full.js')` was causing some problems when actually using tailwindcss. So dropped it instead. * apply `load` -> `loadConfig` changes to `Oxide` engine CLI * ensure we write the config file in the Oxide engine * improve type in Oxide engine CLI * catch errors instead of checking if the file exists A little smaller but just for tests so doesn't matter too much here 👍 * ensure we publish the correct stub files --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com> Co-authored-by: Jordan Pittman <jordan@cryptica.me> Co-authored-by: Nate Moore <nate@natemoo.re> Co-authored-by: Enzo Innocenzi <enzo@innocenzi.dev>
2023-03-15 22:04:18 +01:00
let { combined } = await $(`${EXECUTABLE} init`)
Enable ESM and TS based config files (#10785) * add `jiti` and `detective-typescript` dependencies * use `jiti` and `detective-typescript` Instead of `detective`, this way we will be able to support `tailwind.config.ts` files and `ESM` files. * use `@swc/core` instead of the built-in `babel` form `jiti` * update changelog * add `jiti` and `detective-typescript` dependencies to `stable` * use `sucrase` to transform the configs * add `sucrase` dependency to `stable` engine * make loading the config easier * use abstracted loading config utils * WIP: make `load` related files public API * use new config loader in PostCSS plugin * add list of default config files to look for * cleanup unused arguments * find default config path when using CLI * improve `init` command * make eslint happy * keep all files in `stubs` folder * add `tailwind.config.js` stub file * Initialize PostCSS config using the same format as Tailwind config * Rename config content stubs to config.*.js * Improve option descriptions for init options * Remove unused code, remove `constants` file * Fix TS warning * apply CLI changes to the Oxide version * update `--help` output in CLI tests * WIP: make tests work on CI TODO: Test all combinations of `--full`, `--ts`, `--postcss`, and `--esm`. * wip * remove unused `fs` * Fix init tests Did you know you could pass an empty args to a command? No? Me neither. ¯\_(ツ)_/¯ * bump `napi-derive` * list extensions we are interested in * no-op the `removeFile` if file doesn't exist * ensure all `init` flags work * ensure we cleanup the new files * test ESM/CJS generation based on package.json * remove unnecessary test We are not displaying output in the `--help` anymore based on whether `type: module` is present or not. Therefore this test is unneeded. * only look for `TypeScript` files when the entryFile is `TypeScript` as well * refactor `load` to be `loadConfig` This will allow you to use: ```js import loadConfig from 'tailwindcss/loadConfig' let config = loadConfig("/Users/xyz/projects/my-app/tailwind.config.ts") ``` The `loadConfig` function will return the configuration object based on the given absolute path of a tailwind configuration file. The given path can be a CJS, an ESM or a TS file. * use the `config.full.js` stub instead of the `defaultConfig.stub.js` file The root `defaultConfig` is still there for backwards compatibilty reasons. But the `module.exports = requrie('./config.full.js')` was causing some problems when actually using tailwindcss. So dropped it instead. * apply `load` -> `loadConfig` changes to `Oxide` engine CLI * ensure we write the config file in the Oxide engine * improve type in Oxide engine CLI * catch errors instead of checking if the file exists A little smaller but just for tests so doesn't matter too much here 👍 * ensure we publish the correct stub files --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com> Co-authored-by: Jordan Pittman <jordan@cryptica.me> Co-authored-by: Nate Moore <nate@natemoo.re> Co-authored-by: Enzo Innocenzi <enzo@innocenzi.dev>
2023-03-15 22:04:18 +01:00
expect(combined).toMatchInlineSnapshot(`
"
Created Tailwind CSS config file: tailwind.config.js
"
`)
Enable ESM and TS based config files (#10785) * add `jiti` and `detective-typescript` dependencies * use `jiti` and `detective-typescript` Instead of `detective`, this way we will be able to support `tailwind.config.ts` files and `ESM` files. * use `@swc/core` instead of the built-in `babel` form `jiti` * update changelog * add `jiti` and `detective-typescript` dependencies to `stable` * use `sucrase` to transform the configs * add `sucrase` dependency to `stable` engine * make loading the config easier * use abstracted loading config utils * WIP: make `load` related files public API * use new config loader in PostCSS plugin * add list of default config files to look for * cleanup unused arguments * find default config path when using CLI * improve `init` command * make eslint happy * keep all files in `stubs` folder * add `tailwind.config.js` stub file * Initialize PostCSS config using the same format as Tailwind config * Rename config content stubs to config.*.js * Improve option descriptions for init options * Remove unused code, remove `constants` file * Fix TS warning * apply CLI changes to the Oxide version * update `--help` output in CLI tests * WIP: make tests work on CI TODO: Test all combinations of `--full`, `--ts`, `--postcss`, and `--esm`. * wip * remove unused `fs` * Fix init tests Did you know you could pass an empty args to a command? No? Me neither. ¯\_(ツ)_/¯ * bump `napi-derive` * list extensions we are interested in * no-op the `removeFile` if file doesn't exist * ensure all `init` flags work * ensure we cleanup the new files * test ESM/CJS generation based on package.json * remove unnecessary test We are not displaying output in the `--help` anymore based on whether `type: module` is present or not. Therefore this test is unneeded. * only look for `TypeScript` files when the entryFile is `TypeScript` as well * refactor `load` to be `loadConfig` This will allow you to use: ```js import loadConfig from 'tailwindcss/loadConfig' let config = loadConfig("/Users/xyz/projects/my-app/tailwind.config.ts") ``` The `loadConfig` function will return the configuration object based on the given absolute path of a tailwind configuration file. The given path can be a CJS, an ESM or a TS file. * use the `config.full.js` stub instead of the `defaultConfig.stub.js` file The root `defaultConfig` is still there for backwards compatibilty reasons. But the `module.exports = requrie('./config.full.js')` was causing some problems when actually using tailwindcss. So dropped it instead. * apply `load` -> `loadConfig` changes to `Oxide` engine CLI * ensure we write the config file in the Oxide engine * improve type in Oxide engine CLI * catch errors instead of checking if the file exists A little smaller but just for tests so doesn't matter too much here 👍 * ensure we publish the correct stub files --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com> Co-authored-by: Jordan Pittman <jordan@cryptica.me> Co-authored-by: Nate Moore <nate@natemoo.re> Co-authored-by: Enzo Innocenzi <enzo@innocenzi.dev>
2023-03-15 22:04:18 +01:00
expect(await fileExists('./tailwind.config.js')).toBe(true)
Enable ESM and TS based config files (#10785) * add `jiti` and `detective-typescript` dependencies * use `jiti` and `detective-typescript` Instead of `detective`, this way we will be able to support `tailwind.config.ts` files and `ESM` files. * use `@swc/core` instead of the built-in `babel` form `jiti` * update changelog * add `jiti` and `detective-typescript` dependencies to `stable` * use `sucrase` to transform the configs * add `sucrase` dependency to `stable` engine * make loading the config easier * use abstracted loading config utils * WIP: make `load` related files public API * use new config loader in PostCSS plugin * add list of default config files to look for * cleanup unused arguments * find default config path when using CLI * improve `init` command * make eslint happy * keep all files in `stubs` folder * add `tailwind.config.js` stub file * Initialize PostCSS config using the same format as Tailwind config * Rename config content stubs to config.*.js * Improve option descriptions for init options * Remove unused code, remove `constants` file * Fix TS warning * apply CLI changes to the Oxide version * update `--help` output in CLI tests * WIP: make tests work on CI TODO: Test all combinations of `--full`, `--ts`, `--postcss`, and `--esm`. * wip * remove unused `fs` * Fix init tests Did you know you could pass an empty args to a command? No? Me neither. ¯\_(ツ)_/¯ * bump `napi-derive` * list extensions we are interested in * no-op the `removeFile` if file doesn't exist * ensure all `init` flags work * ensure we cleanup the new files * test ESM/CJS generation based on package.json * remove unnecessary test We are not displaying output in the `--help` anymore based on whether `type: module` is present or not. Therefore this test is unneeded. * only look for `TypeScript` files when the entryFile is `TypeScript` as well * refactor `load` to be `loadConfig` This will allow you to use: ```js import loadConfig from 'tailwindcss/loadConfig' let config = loadConfig("/Users/xyz/projects/my-app/tailwind.config.ts") ``` The `loadConfig` function will return the configuration object based on the given absolute path of a tailwind configuration file. The given path can be a CJS, an ESM or a TS file. * use the `config.full.js` stub instead of the `defaultConfig.stub.js` file The root `defaultConfig` is still there for backwards compatibilty reasons. But the `module.exports = requrie('./config.full.js')` was causing some problems when actually using tailwindcss. So dropped it instead. * apply `load` -> `loadConfig` changes to `Oxide` engine CLI * ensure we write the config file in the Oxide engine * improve type in Oxide engine CLI * catch errors instead of checking if the file exists A little smaller but just for tests so doesn't matter too much here 👍 * ensure we publish the correct stub files --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com> Co-authored-by: Jordan Pittman <jordan@cryptica.me> Co-authored-by: Nate Moore <nate@natemoo.re> Co-authored-by: Enzo Innocenzi <enzo@innocenzi.dev>
2023-03-15 22:04:18 +01:00
// Not a clean way to test this.
expect(await readOutputFile('../tailwind.config.js')).toContain('export default')
await writeInputFile('../package.json', pkg)
})
Enable ESM and TS based config files (#10785) * add `jiti` and `detective-typescript` dependencies * use `jiti` and `detective-typescript` Instead of `detective`, this way we will be able to support `tailwind.config.ts` files and `ESM` files. * use `@swc/core` instead of the built-in `babel` form `jiti` * update changelog * add `jiti` and `detective-typescript` dependencies to `stable` * use `sucrase` to transform the configs * add `sucrase` dependency to `stable` engine * make loading the config easier * use abstracted loading config utils * WIP: make `load` related files public API * use new config loader in PostCSS plugin * add list of default config files to look for * cleanup unused arguments * find default config path when using CLI * improve `init` command * make eslint happy * keep all files in `stubs` folder * add `tailwind.config.js` stub file * Initialize PostCSS config using the same format as Tailwind config * Rename config content stubs to config.*.js * Improve option descriptions for init options * Remove unused code, remove `constants` file * Fix TS warning * apply CLI changes to the Oxide version * update `--help` output in CLI tests * WIP: make tests work on CI TODO: Test all combinations of `--full`, `--ts`, `--postcss`, and `--esm`. * wip * remove unused `fs` * Fix init tests Did you know you could pass an empty args to a command? No? Me neither. ¯\_(ツ)_/¯ * bump `napi-derive` * list extensions we are interested in * no-op the `removeFile` if file doesn't exist * ensure all `init` flags work * ensure we cleanup the new files * test ESM/CJS generation based on package.json * remove unnecessary test We are not displaying output in the `--help` anymore based on whether `type: module` is present or not. Therefore this test is unneeded. * only look for `TypeScript` files when the entryFile is `TypeScript` as well * refactor `load` to be `loadConfig` This will allow you to use: ```js import loadConfig from 'tailwindcss/loadConfig' let config = loadConfig("/Users/xyz/projects/my-app/tailwind.config.ts") ``` The `loadConfig` function will return the configuration object based on the given absolute path of a tailwind configuration file. The given path can be a CJS, an ESM or a TS file. * use the `config.full.js` stub instead of the `defaultConfig.stub.js` file The root `defaultConfig` is still there for backwards compatibilty reasons. But the `module.exports = requrie('./config.full.js')` was causing some problems when actually using tailwindcss. So dropped it instead. * apply `load` -> `loadConfig` changes to `Oxide` engine CLI * ensure we write the config file in the Oxide engine * improve type in Oxide engine CLI * catch errors instead of checking if the file exists A little smaller but just for tests so doesn't matter too much here 👍 * ensure we publish the correct stub files --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com> Co-authored-by: Jordan Pittman <jordan@cryptica.me> Co-authored-by: Nate Moore <nate@natemoo.re> Co-authored-by: Enzo Innocenzi <enzo@innocenzi.dev>
2023-03-15 22:04:18 +01:00
test('CJS config is created by default in a non-ESM project', async () => {
await removeFile('tailwind.config.js')
let pkg = await readOutputFile('../package.json')
await writeInputFile(
'../package.json',
JSON.stringify({
...JSON.parse(pkg),
})
)
let { combined } = await $(`${EXECUTABLE} init`)
expect(combined).toMatchInlineSnapshot(`
"
Enable ESM and TS based config files (#10785) * add `jiti` and `detective-typescript` dependencies * use `jiti` and `detective-typescript` Instead of `detective`, this way we will be able to support `tailwind.config.ts` files and `ESM` files. * use `@swc/core` instead of the built-in `babel` form `jiti` * update changelog * add `jiti` and `detective-typescript` dependencies to `stable` * use `sucrase` to transform the configs * add `sucrase` dependency to `stable` engine * make loading the config easier * use abstracted loading config utils * WIP: make `load` related files public API * use new config loader in PostCSS plugin * add list of default config files to look for * cleanup unused arguments * find default config path when using CLI * improve `init` command * make eslint happy * keep all files in `stubs` folder * add `tailwind.config.js` stub file * Initialize PostCSS config using the same format as Tailwind config * Rename config content stubs to config.*.js * Improve option descriptions for init options * Remove unused code, remove `constants` file * Fix TS warning * apply CLI changes to the Oxide version * update `--help` output in CLI tests * WIP: make tests work on CI TODO: Test all combinations of `--full`, `--ts`, `--postcss`, and `--esm`. * wip * remove unused `fs` * Fix init tests Did you know you could pass an empty args to a command? No? Me neither. ¯\_(ツ)_/¯ * bump `napi-derive` * list extensions we are interested in * no-op the `removeFile` if file doesn't exist * ensure all `init` flags work * ensure we cleanup the new files * test ESM/CJS generation based on package.json * remove unnecessary test We are not displaying output in the `--help` anymore based on whether `type: module` is present or not. Therefore this test is unneeded. * only look for `TypeScript` files when the entryFile is `TypeScript` as well * refactor `load` to be `loadConfig` This will allow you to use: ```js import loadConfig from 'tailwindcss/loadConfig' let config = loadConfig("/Users/xyz/projects/my-app/tailwind.config.ts") ``` The `loadConfig` function will return the configuration object based on the given absolute path of a tailwind configuration file. The given path can be a CJS, an ESM or a TS file. * use the `config.full.js` stub instead of the `defaultConfig.stub.js` file The root `defaultConfig` is still there for backwards compatibilty reasons. But the `module.exports = requrie('./config.full.js')` was causing some problems when actually using tailwindcss. So dropped it instead. * apply `load` -> `loadConfig` changes to `Oxide` engine CLI * ensure we write the config file in the Oxide engine * improve type in Oxide engine CLI * catch errors instead of checking if the file exists A little smaller but just for tests so doesn't matter too much here 👍 * ensure we publish the correct stub files --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com> Co-authored-by: Jordan Pittman <jordan@cryptica.me> Co-authored-by: Nate Moore <nate@natemoo.re> Co-authored-by: Enzo Innocenzi <enzo@innocenzi.dev>
2023-03-15 22:04:18 +01:00
Created Tailwind CSS config file: tailwind.config.js
"
`)
Enable ESM and TS based config files (#10785) * add `jiti` and `detective-typescript` dependencies * use `jiti` and `detective-typescript` Instead of `detective`, this way we will be able to support `tailwind.config.ts` files and `ESM` files. * use `@swc/core` instead of the built-in `babel` form `jiti` * update changelog * add `jiti` and `detective-typescript` dependencies to `stable` * use `sucrase` to transform the configs * add `sucrase` dependency to `stable` engine * make loading the config easier * use abstracted loading config utils * WIP: make `load` related files public API * use new config loader in PostCSS plugin * add list of default config files to look for * cleanup unused arguments * find default config path when using CLI * improve `init` command * make eslint happy * keep all files in `stubs` folder * add `tailwind.config.js` stub file * Initialize PostCSS config using the same format as Tailwind config * Rename config content stubs to config.*.js * Improve option descriptions for init options * Remove unused code, remove `constants` file * Fix TS warning * apply CLI changes to the Oxide version * update `--help` output in CLI tests * WIP: make tests work on CI TODO: Test all combinations of `--full`, `--ts`, `--postcss`, and `--esm`. * wip * remove unused `fs` * Fix init tests Did you know you could pass an empty args to a command? No? Me neither. ¯\_(ツ)_/¯ * bump `napi-derive` * list extensions we are interested in * no-op the `removeFile` if file doesn't exist * ensure all `init` flags work * ensure we cleanup the new files * test ESM/CJS generation based on package.json * remove unnecessary test We are not displaying output in the `--help` anymore based on whether `type: module` is present or not. Therefore this test is unneeded. * only look for `TypeScript` files when the entryFile is `TypeScript` as well * refactor `load` to be `loadConfig` This will allow you to use: ```js import loadConfig from 'tailwindcss/loadConfig' let config = loadConfig("/Users/xyz/projects/my-app/tailwind.config.ts") ``` The `loadConfig` function will return the configuration object based on the given absolute path of a tailwind configuration file. The given path can be a CJS, an ESM or a TS file. * use the `config.full.js` stub instead of the `defaultConfig.stub.js` file The root `defaultConfig` is still there for backwards compatibilty reasons. But the `module.exports = requrie('./config.full.js')` was causing some problems when actually using tailwindcss. So dropped it instead. * apply `load` -> `loadConfig` changes to `Oxide` engine CLI * ensure we write the config file in the Oxide engine * improve type in Oxide engine CLI * catch errors instead of checking if the file exists A little smaller but just for tests so doesn't matter too much here 👍 * ensure we publish the correct stub files --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com> Co-authored-by: Jordan Pittman <jordan@cryptica.me> Co-authored-by: Nate Moore <nate@natemoo.re> Co-authored-by: Enzo Innocenzi <enzo@innocenzi.dev>
2023-03-15 22:04:18 +01:00
expect(await fileExists('./tailwind.config.js')).toBe(true)
// Not a clean way to test this.
Enable ESM and TS based config files (#10785) * add `jiti` and `detective-typescript` dependencies * use `jiti` and `detective-typescript` Instead of `detective`, this way we will be able to support `tailwind.config.ts` files and `ESM` files. * use `@swc/core` instead of the built-in `babel` form `jiti` * update changelog * add `jiti` and `detective-typescript` dependencies to `stable` * use `sucrase` to transform the configs * add `sucrase` dependency to `stable` engine * make loading the config easier * use abstracted loading config utils * WIP: make `load` related files public API * use new config loader in PostCSS plugin * add list of default config files to look for * cleanup unused arguments * find default config path when using CLI * improve `init` command * make eslint happy * keep all files in `stubs` folder * add `tailwind.config.js` stub file * Initialize PostCSS config using the same format as Tailwind config * Rename config content stubs to config.*.js * Improve option descriptions for init options * Remove unused code, remove `constants` file * Fix TS warning * apply CLI changes to the Oxide version * update `--help` output in CLI tests * WIP: make tests work on CI TODO: Test all combinations of `--full`, `--ts`, `--postcss`, and `--esm`. * wip * remove unused `fs` * Fix init tests Did you know you could pass an empty args to a command? No? Me neither. ¯\_(ツ)_/¯ * bump `napi-derive` * list extensions we are interested in * no-op the `removeFile` if file doesn't exist * ensure all `init` flags work * ensure we cleanup the new files * test ESM/CJS generation based on package.json * remove unnecessary test We are not displaying output in the `--help` anymore based on whether `type: module` is present or not. Therefore this test is unneeded. * only look for `TypeScript` files when the entryFile is `TypeScript` as well * refactor `load` to be `loadConfig` This will allow you to use: ```js import loadConfig from 'tailwindcss/loadConfig' let config = loadConfig("/Users/xyz/projects/my-app/tailwind.config.ts") ``` The `loadConfig` function will return the configuration object based on the given absolute path of a tailwind configuration file. The given path can be a CJS, an ESM or a TS file. * use the `config.full.js` stub instead of the `defaultConfig.stub.js` file The root `defaultConfig` is still there for backwards compatibilty reasons. But the `module.exports = requrie('./config.full.js')` was causing some problems when actually using tailwindcss. So dropped it instead. * apply `load` -> `loadConfig` changes to `Oxide` engine CLI * ensure we write the config file in the Oxide engine * improve type in Oxide engine CLI * catch errors instead of checking if the file exists A little smaller but just for tests so doesn't matter too much here 👍 * ensure we publish the correct stub files --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com> Co-authored-by: Jordan Pittman <jordan@cryptica.me> Co-authored-by: Nate Moore <nate@natemoo.re> Co-authored-by: Enzo Innocenzi <enzo@innocenzi.dev>
2023-03-15 22:04:18 +01:00
expect(await readOutputFile('../tailwind.config.js')).toContain('module.exports')
await writeInputFile('../package.json', pkg)
})
})