tailwindcss/tests/context-reuse.test.js
Robin Malfait 581cf6abcc
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-24 22:10:00 -04:00

128 lines
3.7 KiB
JavaScript

import { css } from './util/run'
const fs = require('fs')
const path = require('path')
const postcss = require('postcss')
const tailwind = require('../src/index.js')
const sharedState = require('../src/lib/sharedState.js')
const configPath = path.resolve(__dirname, './context-reuse.tailwind.config.js')
function run(input, config = {}, from = null) {
let { currentTestName } = expect.getState()
from = `${path.resolve(__filename)}?test=${currentTestName}&${from}`
return postcss(tailwind(config)).process(input, { from })
}
beforeEach(async () => {
let config = {
content: [path.resolve(__dirname, './context-reuse.test.html')],
corePlugins: { preflight: false },
}
await fs.promises.writeFile(configPath, `module.exports = ${JSON.stringify(config)};`)
})
afterEach(async () => {
await fs.promises.unlink(configPath)
})
test('re-uses the context across multiple files with the same config', async () => {
let results = [
await run(`@tailwind utilities;`, configPath, `id=1`),
// Using @apply directives should still re-use the context
// They depend on the config but do not the other way around
await run(`body { @apply bg-blue-400; }`, configPath, `id=2`),
await run(`body { @apply text-red-400; }`, configPath, `id=3`),
await run(`body { @apply mb-4; }`, configPath, `id=4`),
]
let dependencies = results.map((result) => {
return result.messages
.filter((message) => message.type === 'dependency')
.map((message) => message.file)
})
// The content files don't have any utilities in them so this should be empty
expect(results[0].css).toMatchFormattedCss(css``)
// However, @apply is being used so we want to verify that they're being inlined into the CSS rules
expect(results[1].css).toMatchFormattedCss(css`
body {
--tw-bg-opacity: 1;
background-color: rgb(96 165 250 / var(--tw-bg-opacity));
}
`)
expect(results[2].css).toMatchFormattedCss(css`
body {
--tw-text-opacity: 1;
color: rgb(248 113 113 / var(--tw-text-opacity));
}
`)
expect(results[3].css).toMatchFormattedCss(css`
body {
margin-bottom: 1rem;
}
`)
// Files with @tailwind directives depends on the PostCSS tree, config, AND any content files
expect(dependencies[0]).toEqual([
path.resolve(__dirname, 'context-reuse.test.html'),
path.resolve(__dirname, 'context-reuse.tailwind.config.js'),
])
// @apply depends only on the containing PostCSS tree *and* the config file but no content files
// as they cannot affect the outcome of the @apply directives
expect(dependencies[1]).toEqual([path.resolve(__dirname, 'context-reuse.tailwind.config.js')])
expect(dependencies[2]).toEqual([path.resolve(__dirname, 'context-reuse.tailwind.config.js')])
expect(dependencies[3]).toEqual([path.resolve(__dirname, 'context-reuse.tailwind.config.js')])
// And none of this should have resulted in multiple contexts being created
expect(sharedState.contextSourcesMap.size).toBe(1)
})
test('updates layers when any CSS containing @tailwind directives changes', async () => {
let result
// Compile the initial version once
let input = css`
@tailwind utilities;
@layer utilities {
.custom-utility {
color: orange;
}
}
`
result = await run(input, configPath, `id=1`)
expect(result.css).toMatchFormattedCss(css`
.only\:custom-utility:only-child {
color: orange;
}
`)
// Save the file with a change
input = css`
@tailwind utilities;
@layer utilities {
.custom-utility {
color: blue;
}
}
`
result = await run(input, configPath, `id=1`)
expect(result.css).toMatchFormattedCss(css`
.only\:custom-utility:only-child {
color: #00f;
}
`)
})