* `cargo clippy --fix`
* use `map_while` instead of `filter_map`
- `filter_map()` will run forever if the iterator repeatedly produces an `Err`
```
❯ cargo clippy
Checking tailwindcss-oxide v0.1.0 (/Users/robin/github.com/tailwindlabs/tailwindcss/oxide/crates/cli)
warning: `filter_map()` will run forever if the iterator repeatedly produces an `Err`
--> crates/cli/src/main.rs:108:14
|
108 | .filter_map(Result::ok)
| ^^^^^^^^^^^^^^^^^^^^^^ help: replace with: `map_while(Result::ok)`
|
note: this expression returning a `std::io::Lines` may produce an infinite number of `Err` in case of a read error
--> crates/cli/src/main.rs:106:9
|
106 | / read_lines(path)
107 | | .unwrap()
| |_____________________^
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#lines_filter_map_ok
= note: `#[warn(clippy::lines_filter_map_ok)]` on by default
warning: `tailwindcss-oxide` (bin "tailwindcss-oxide") generated 1 warning
Finished dev [unoptimized + debuginfo] target(s) in 0.13s
```
* log used versions of all the tools we are using
* ensure we install Rust
* 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>
* Don’t move `::deep` pseudo element to end of selector when using `@apply`
* Update changelog
* Move pseudo-elements in two passes
* Rewrite pseudo-element relocation logic
* Update test
`::test` is an unknown pseudo element and therefore may be actionable _and_ nestable
* Add tests
* Simplify tests
* Simplify
* run tests on CI multiple times
This works around the timeouts/flakeyness of GitHub Actions
* Update formatting
* Add comment
* Mark webkit peusdo elements as terminal
* update comment
* only execute the `global-setup` once
* Simplify
NO SORT FN YAY
* Use typedefs
* Update changelog
* Update changelog
* update again
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
* cache the `oxide` targets
This will cache the oxide related build files to hopefully minimize the
amount of Rust compiling.
* tmp: drop turbo
* cache `./oxide/target/`
Thanks @thecrypticace!
* no need to cache `oxide` files
This will already be cached by GitHub actions. This should save us many
GBs on Vercel.com and Rust (or Cargo) is way better in using existing
cached information so this mix of caches between Turbo and GitHub
actions is kind of nice.
* Revert "tmp: drop turbo"
This reverts commit 22761d3a66.
* improve caching for integration tests and insiders release
* separate `stable` and `oxide` mode (package.json in this case)
* drop `install` script (we use a workspace now)
* change required engine to 16
* enable OXIDE by default
* ignore generated `oxide` files
* splitup package.json scripts into "public" and "private" scripts
Not ideal of course, but this should make it a tiny bit easier to know
which scripts _you_ as a developer / contributor have to run.
* drop `workspaces` from the `stable` engine
* drop `oxide` related build files from the `stable` engine
* drop `oxide` engine specific dependencies from the `stable` engine
* use the `oxide-node-api-shim` for the `stable` engine
* add little script to swap the engines
* drop `oxide:build` from `turbo` config
* configure `ci` for `stable` and `oxide` engines
- rename `nodejs.yml` -> `ci.yml`
- add `ci-stable.yml` (for stable mode and Node 12)
- ensure to use the `stable` engine in the `ci-stable.yml` workflow
- drop `oxide:___` specific scripts
* rename `release-insiders` to `release-insiders-stable`
This way we will be able to remove all files that contain `stable` once
we are ready.
* rename `release-insiders-oxide` to just `release-insiders`
* cleanup insider related workflows
* rename `release` -> `release-stable`
* rename `release-oxide` -> `release`
* change names of release workflows
* drop `oxide-` prefix from jobs
* inline node versions
* do not use `turbo` for the stable build
Can't use it because we don't have a workspace in the stable build.
* re-rename CI workflow
* encode default engine in relevant `package.json` files
* make Node 12 work
* increase `node-version` matrix
* make release workflows explicit (per engine)
* add `Oxide` to workflow name
* add integration tests for the `oxide` engine
* add integration tests for the `stable` engine
* run `oxide` integrations against node `18`
* run `stable` integration tests against node 18
We should test node 12 for tailwindcss, but integrations itself can run
against a newer version. In fact, we always ran them against node 16.
* use `localhost` instead of `0.0.0.0`
* ensure `webpack-4` works on Node 18
* run relese scripst directly
Instead of going via `npm`. It's a bit nicer and quicker!
* drop unused scripts
* sync package-lock.json
* ensure to generate the plugin list before running `jest`
We _could_ use an `npm run pretest`, but then you can't run `jest`
directly anymore (which is required for some tools like vscode
extensions).
* cleanup npm scripts
* drop pretend comments
* fix typo
* add `build:rust` as a pre-jest run script
