* 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>
* replace `env.OXIDE` with global `__OXIDE__`
This will allow us to replace the `__OXIDE__` at build time, and fully
remove the branches from the final code so that there is not even any
reference to `@tailwindcss/oxide` on the stable engine.
* update changelog
* use `env.ENGINE` in integration tests
* drop oxide branching for the PostCSS plugin for now
This is currently a redirect to the same file, so doesn't hurt.
* Enable better dead-code elimination
* Update CLI tests
Fix indentation
* Fix indentation
---------
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* temporarily disable workflows
* add oxide
Our Rust related parts
* use oxide
- Setup the codebase to be able to use the Rust parts based on an
environment variable: `OXIDE=1`.
- Setup some tests that run both the non-Rust and Rust version in the
same test.
- Sort the candidates in a consistent way, to guarantee the order for
now (especially in tests).
- Reflect sorting related changes in tests.
- Ensure tests run in both the Rust and non-Rust version. (Some tests
are explicitly skipped when using the Rust version since we haven't
implemented those features yet. These include: custom prefix,
transformers and extractors).
- `jest`
-`OXIDE=1 jest`
* remove into_par_iter where it doesn't make sense
* cargo fmt
* wip
* enable tracing based on `DEBUG` env
* improve CI for the Oxide build
* sort test output
This happened because the sorting happens in this branch, but changes
happened on the `master` branch.
* add failing tests
I noticed that some of the tests were failing, and while looking at
them, it happened because the tests were structured like this:
```html
<div
class="
backdrop-filter
backdrop-filter-none
backdrop-blur-lg
backdrop-brightness-50
backdrop-contrast-0
backdrop-grayscale
backdrop-hue-rotate-90
backdrop-invert
backdrop-opacity-75
backdrop-saturate-150
backdrop-sepia
"
></div>
```
This means that the class names themselves eventually end up like this: `backdrop-filter-none\n`
-> (Notice the `\n`)
/cc @thecrypticace
* fix range to include `\n`
* Include only unique values for tests
Really, what we care about most is that the list contains every expected candidate. Not necessarily how many times it shows up because while many candidates will show up A LOT in a source text we’ll unique them before passing them back to anything that needs them
* Fix failing tests
* Don’t match empty arbitrary values
* skip tests in oxide mode regarding custom separators in arbitrary variants
* re-enable workflows
* use `@tailwindcss/oxide` dependency
* publish `tailwindcss@oxide`
* drop prepublishOnly
I don't think we actually need this anymore (or even want because this
is trying to do things in CI that we don't want to happen. Aka, build
the Oxide Rust code, it is already a dependency).
* WIP
* Defer to existing CLI for Oxide
* Include new compiled typescript stuff when publishing
* Move TS to ./src/oxide
* Update scripts
* Clean up tests for TS
* copy `cli` to `oxide/cli`
* make CLI files TypeScript files
* drop --postcss flag
* setup lightningcss
* Remove autoprefixer and cssnano from oxide CLI
* cleanup Rust code a little bit
- Drop commented out code
- Drop 500 fixture templates
* sort test output
* re-add `prepublishOnly` script
* bump SWC dependencies in package-lock.json
* pin `@swc` dependencies
* ensure to install and build oxide
* update all GitHub Workflows to reflect Oxide required changes
* sort `content-resolution` integration tests
* add `Release Insiders — Oxide`
* setup turbo repo + remote caching
* use `npx` to invoke `turbo`
* setup unique/proper package names for integration tests
* add missing `isomorphic-fetch` dependency
* setup integration tests to use `turborepo`
* scope tailwind tasks to root workspace
* re-enable `node_modules` cache for integration tests
* re-enable `node_modules` cache for main CI workflow
* split cache for `main` and `oxide` node_modules
* fix indent
* split install dependencies so that they can be cached individually
* improve GitHub actions caching
* use correct path for oxide node_modules (crates/node)
* ensure that `cargo install` always succeeds
cargo install X, on CI will fail if it already exists.
* figure out integration tests with turbo
* tmp: use `npm` instead of `turbo`
* disable `fail-fast`
This will allow us to run integration tests so that it still caches the
succesful ones.
* YAML OH YAML, Y U WHITESPACE SENSITIVE
* copy the oxide-ci workflow to release-oxide
* make `oxide-ci` a normal CI workflow
Without publishing
* try to cache cargo and node_modules for the oxide build
* configure turbo to run scripts in the root
* explicitly skip failing test for the Oxide version
* run oxide tests in CI
* only use build script for root package
* sync package-lock.json
* do not cache node_modules for each individual integration
* look for hoisted `.bin`
* use turbo for caching build tailwind css in integration tests
* Robin...
* try to use the local binary first
* skip installing integration test dependencies
Should already be installed due to workspace usage
* Robin...
* drop `output.clean`
* explicitly add `mini-css-extract-plugin`
* drop oxide-ci, this is tested by proxy
* ensure oxide build is used in integration tests
This will ensure the `@tailwindcss/oxide` dependency is available
(whether we use it or not).
* setup Oxide shim in insiders release
* add browserslist dependency
* use `install:all` script name
Just using `install` as a script name will be called when running
`npm install`.
Now that we marked the repo as a `workspace`, `npm install` will run
install in all workspaces which is... not ideal.
* tmp: enable insiders release in PRs
Just to check if everything works before merging. Can be removed once
tested.
* don't cache node_modules?
I feel there is some catch 22 going on here.
We require `npm install` to build the `oxide/crates/node` version.
But we also require `oxide/crates/node` for the `npm install` becaus of
the dependency: `"@tailwindcss/oxide": "file:oxide/creates/node"`
* try to use `oxide/crates/node` as part of the workspace
* let's think about this
Let's try and cache the `node_modules` and share as much as possible.
However, some scripts still need to be installed specific to the OS.
Running `npm install` locally doesn't throw away your `node_modules`,
so if we just cache `node_modules` but also run `npm install` that
should keep as much as possible and still improve install times since
`node_modules` is already there.
I think.
* ensure generated `index.js` and `index.d.ts` files are considered outputs
* use `npx napi` instead of `napi` directly
* include all `package-lock.json` files
* normalize caching further in all workflows
* drop nested `package-lock.json` files
* `npm uninstall mini-css-extract-plugin && npm install mini-css-extract-plugin --save-dev`
* bump webpack-5 integration tests dependencies
* only release insiders on `master` branch
* tmp: let's figure out release insiders oxide
* fix little typo
* use Node 18 for Oxide Insiders
* syncup package-lock.json
* let's try node 16
Node 18 currently fails on `Build x86_64-unknown-linux-gnu (OXIDE)`
Workflow.
Install Node.JS output:
```
Environment details
Warning: /__t/node/18.13.0/x64/bin/node: /lib64/libm.so.6: version `GLIBC_2.27' not found (required by /__t/node/18.13.0/x64/bin/node)
/__t/node/18.13.0/x64/bin/node: /lib64/libc.so.6: version `GLIBC_2.25' not found (required by /__t/node/18.13.0/x64/bin/node)
/__t/node/18.13.0/x64/bin/node: /lib64/libc.so.6: version `GLIBC_2.28' not found (required by /__t/node/18.13.0/x64/bin/node)
/__t/node/18.13.0/x64/bin/node: /lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by /__t/node/18.13.0/x64/bin/node)
/__t/node/18.13.0/x64/bin/node: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /__t/node/18.13.0/x64/bin/node)
/__t/node/18.13.0/x64/bin/node: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /__t/node/18.13.0/x64/bin/node)
Warning: node: /lib64/libm.so.6: version `GLIBC_2.27' not found (required by node)
node: /lib64/libc.so.6: version `GLIBC_2.25' not found (required by node)
node: /lib64/libc.so.6: version `GLIBC_2.28' not found (required by node)
node: /lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by node)
node: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by node)
node: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by node)
```
* bump some Node versions
* only release oxide insiders on `master` branch
* don't cache `npm`
* bump napi-rs
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
* Update lockfile
* Tweak formatting
* Refactor content path parsing
* Allow resolving content paths relative to the config file
* Include resolved symlinks as additional content paths
* Update changelog
* Work on suite of tests for content resolution
* reformat integration test list
* Move content resolution tests to integration
* Update future and experimental types
* Don’t re-add files in the CLI watcher that are covered by dynamic patterns
They don’t have the same problem. As long as the parent directory is watched their add/change events will fire correctly
* Ignore raw events for files that don’t match the content files
* fixup
* Update changelog
* Fix CLI not watching atomically renamed files
Chokdar should take care of this itself but sometimes it doesn’t do so OR is otherwise very sensitive to timing problems
* Force chokidar to always check for atomic writes
* Handle repeated atomic saves by retrying file reads
* Update changelog
* Add support for postcss-import in watch mode
* Add regression test
* Extract shared logic
* restructure test a little bit
Instead of relying on a arbitrary setTimout value, let's wait for the
file to be created instead.
* update changelog
Co-authored-by: Adam Bergman <adam@fransvilhelm.com>
* ensure we can use `@import 'tailwindcss/...'` without node_modules
This is useful if you are using `npx tailwindcs ...` and to prevent
that postcss-import crashes on the tailwind specific imports which we
will replace anyway.
* update changelog
* add generate-types script
This script will generate the full list of core plugins, which will
allow you to get code completion for the `corePlugins` section.
It will also generate all the colors (and deprecated colors) which is
used in multiple places in the config.
* add types for the `tailwind.config.js` config file
* annotate stubs with a JSDoc pointing to the types
* add types to package.json
- Updated the files to make sure that the types are being published
- Add a `types` section in the `package.json`, otherwise your editor by
default will look for the `DefinitelyTyped` types which got me really
confused for a second.
- Added some scripts to make sure that the generation of types happens
when needed (before tests and before building). This way you never
ever have to think about generating them when working on Tailwind CSS
internals.
* re-export types top-level
Having a `colors.d.ts` next to the `colors.js` file allows us to type
the `colors.js` file and your editor will pickup the types from
`colors.d.ts`.
* also publish generated types
* update changelog
* enable TypeScript only when using `init --types` for now
* update tests to verify that `--types` works
* ensure content files are available in config
If you use the cli with the `--content` option, then we first resolve
the config (empty), then add the `content` to the config. The issue is
that this means that the content will be empty when you resolve it
initially. This results in a warning in your terminal.
Now, we will make sure to merge 2 configs if you have the `--content`
data passed. We will also make sure to override the final
`config.content.files` to whatever you passed in to make sure that this
is the same behaviour as before.
* update changelog
* use outputFile instead of direct writeFile
This is an improvement we introduced earlier but forgot this part.
* allow to pipe in data to the CLI
* add integration tests to validate piping to the CLI
* update changelog
* fix(cli): avoid write same output when no changes
* generalize outputFile
This function will check a cache, it will only write the file if:
- The modified timestamps changed since last time we wrote something.
This is useful to know if something changed by another tool or
manually without diffing the full file.
- The contents changed.
* further simplify checks
Turns out that reading files and comparing them is fairly fast and there
is no huge benefit over only using the Stats of the file and keeping
track of that information.
Thanks @kentcdodds!
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
* immediately take the `safelist` values into account
Currently we had to manually add them in the `setupTrackingContext`,
`setupWatchingContext` and the `cli`.
This was a bit cumbersome, because the `safelist` function (to resolve
regex patterns) was implemented on the context. This means that we had
to do something like this:
```js
let changedContent = []
let context = createContext(config, changedContent)
for (let content of context.safelist()) {
changedContent.push(content)
}
```
This just feels wrong in general, so now it is handled internally for
you which means that we can't mess it up anymore in those 3 spots.
* drop the dot from the extension
Our transformers and extractors are implemented for `html` for example.
However the `path.extname()` returns `.html`.
This isn't an issue by default, but it could be for with custom
extractors / transformers.
* normalize the configuration
* make shared cache local per extractor
* ensure we always have an `extension`
Defaults to `html`
* splitup custom-extractors test
* update old config structure to new structure
* ensure we validate the "old" structure, and warn if invalid
* add tests with "old" config, to ensure it keeps working
* add missing `content` object
* inline unnecessary function abstraction
* 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
Do not require NODE_ENV to be set to 'production' as well, as using
the --purge option in the CLI should be explicit enough.
Co-authored-by: Arnout Roemers <roemers@zorgdomein.nl>
* add tests for the --postcss option in the new CLI
* add `oneOf` ability to the `arg()` functionality
By default, `arg()` doesn't have a way to define multiple types. We want
the possibility of using `--postcss` (Boolean) or `--postcss
./custom-path.js`. But by default this is not possible.
This commit will allow us to do a few things, mainly:
- Keep the same API using the `{ type: oneOf(String, Boolean), description: '...' }`
- Keep the `--help` output similar
What we did behind the scenes is make sure to put the non recognized
flags in the `_` arguments list. This is possible by doing `permissive:
true`. We then manually parse those and resolve the correct value.
* ensure that we can use a custom `--postcss ./with-custom-path.js`
* fix --help output in tests
* add tests to ensure we can use `purge.safelist`
* implement the `purge.safelist` for strings
* proxy `purge.safelist` to `purge.options.safelist`
This allows us to have a similar API in `AOT` and `JIT` mode.
* only proxy `purge.safelist` to `purge.options.safelist` if
`purge.options.safelist` doesn't exists yet.
