* use `defaults` for `browserslist`
+ some features that we require for Tailwind to work.
* simplify Lightning CSS features
Always transpile `Nesting`, never transpile `LogicalProperties`.
* bump caniuse-lite (`npx browserslist@latest --update-db`)
* reflect changes in the tests
* update changelog
* 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
* remove `autoprefixer` dependency
This was only used in the CLI and we are not using it anymore. The
functionality of `autoprefixer` is baked into `lightningcss`.
* update changelog
* 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>
* resolve all _existing_ content paths
* pin `@napi-rs/cli`
* WIP: Log all resolved content files/globs
* only filter out raw changed content in non-auto mode
* skip parseCandidateFiles cache in `auto` mode
* improve algorithm of detecting content paths
1. Files in the root should be listed statically instead of using globs.
2. Files and folders in special known direct child folders should be
listed statically instead of using globs (e.g.: `public`). This is
because these special folders are often used to store generated AND
source files at the same time. Using globs could trigger infinite
loops because we are watching and acting upon dist files.
3. All file extensions found in the project, should be used in the globs
in addition to a known set of extensions.
4. Direct folders seen from the root, can use the glob syntax
`<root>/src/**/*.{...known-extensions}`
* inline wanted-extensions
Not 100% convinced yet, but seems cleaner so far.
* ensure writing an file also makes the parent folder(s)
* add integration tests for the auto content feature
* add pnpm and bun lock files
* Revert "inline wanted-extensions"
This reverts commit 879c1248524e84216125f4a24e0160b40736333a.
* sort binary-extensions and add lockb
* sort + add `lock` to ignored extensions
* drop `yarn.lock`, because lock extensions are already covered
* group template extensions
This will make it a bit easier to organize in the future.
* drop empty lines and commented lines from template-extensions
* skip the config path when resolving template files
The config file will automatically trigger a rebuild when this file is
changed. However, this should not be part of the template files because
that could cause additional css that's not being used.
* make `auto content` the default in the oxide engine
- In the oxide engine, the default `content: []` will be dropped from
the default configuration (config.simple.js, config.full.js).
- If you have `content: []` or `content: { files: [] }` then the auto
content feature won't be active. However if those arrays are empty a
warning will still be shown. Adding files/globs or dropping the
`content` section completely will enable auto content.
* only test the auto content integration test in the oxide engine
* set `content.files` to `auto` instead of using `auto: boolean`
This way we don't run into the issue where the `config.content.files` is
set and the `config.content.auto` is set to true.
* drop log
* ensure we validate the config in the CLI
* show experimental warning for automatic content detection
* use cached version of the getCandidateFiles instead of bypassing it
* use `is_empty()` shorthand
Thanks, Clippy!
* add test to ensure nested ignored folders are not scanned
* add `tempfile` for tests
* add auto content tests in Rust
* refactor auto content detection
This will also make sure that if we have (deeply) nested ignored
folders, then we won't use deeply nested globs (**/*.{js,html}) for the
parent(s) of the nested ignored folders but instead use a shallow glob
for each directory (*/*.{js,html}).
Then each sibling directory of the parent can use deeply nested globs
again except for the direct parent.
* use consistent comments
* ensure ignored static listed files are not present
* improve performance by ~30x
On a big test project this goes from ~6s to ~200ms
* improve performance by ~5x
We started with a ~6s duration
Then in the previous commit, we improved it by ~30x and it went down to
~200ms
Now with this change, it takes about ~40ms. That's another ~5x
improvement.
Or in total a ~150x improvement.
* ensure nested folders in `public/` are also explicitly listed
* add shortcut for normalizing files
This is only called once so won't do anything to the main performance of
Tailwind CSS. But always nice to make small performance improvements!
* run Rust tests in CI
* fix lint warnings
* update changelog
* Update CHANGELOG.md
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
