Commit graph

5 commits

Author SHA1 Message Date
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
Robin Malfait
e17855b4d4
Fine-tune turbo.json config to improve cache hits (#10377)
* play with turbo configuration

* tmp: random change, let's test caches

* remove unnecessary inputs

Inputs are implicit via the `"dependsOn": ["//#build"],`

* use `inputs` instead of `outputs` for `//#style`

* Revert "tmp: random change, let's test caches"

This reverts commit 77e9be6dc4.

* remove empty `outputs` configs
2023-01-21 01:06:41 +01:00
Robin Malfait
f9d0c1e7df
Cache the oxide targets (#10374)
* 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
2023-01-20 22:50:32 +01:00
Robin Malfait
b1f4da70d1
Separate stable and oxide engines (#10359)
* 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
2023-01-19 11:58:25 -05:00
Robin Malfait
2a403267d8
Oxide (#10252)
* 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>
2023-01-13 12:22:00 +01:00