Commit graph

5 commits

Author SHA1 Message Date
Adam Wathan
dce8280d76
[Oxide] Automatic content detection (#11173)
* 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>
2023-05-12 18:49:35 +02:00
Jordan Pittman
e3a9d5f53b
Don’t move unknown pseudo-elements to the end of selectors (#10962)
* 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>
2023-04-07 10:45:47 -04:00
Robin Malfait
3193dae61d
ensure workflows run for the 3.3 branch 2023-03-29 23:03:37 +02: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