This reverts #16211
We found some unexpected interactions with using `@apply` and CSS
variables in multi-root setups like CSS modules or Vue inline `<style>`
blocks that were broken due to that change. We plan to re-enable this
soon and include a proper fix for those scenarios.
## Test plan
- Updated snapshots
- Tested using the CLI in a new project:
<img width="1523" alt="Screenshot 2025-02-10 at 13 08 42"
src="https://github.com/user-attachments/assets/defe0858-adb3-4d61-9d2c-87166558fd68"
/>
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
Closes#15731
This PR adds a FreeBSD build target to our CI workflows. It was tested
on CI:
https://github.com/tailwindlabs/tailwindcss/actions/runs/13159185517/job/36723613079
However, due to the build not emitting final npm packages, we don't have
a way to actually test the final package before we ship it to an
insiders release.
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
Now that Tailwind CSS v4 is released, we can setup a proper release
workflow again. This setup mimics the workflow of how we did it in v3,
but adjusted to make it work on the v4 codebase.
Whenever a PR is merged into the `next` branch, we will publish an
insiders release to npm using the following version number:
`0.0.0-insiders.<commit-hash>`. Note: insiders releases will not have a
GitHub release associated with them, therefore the `standalone-cli`
won't be available as an insiders release.
For the normal release procedure, the following steps are required:
1. Manually version the packages (e.g.: `pnpm run version-packages`)
2. Create a git tag for the version you want to release
3. Push the updated package.json files and the git tag to the repository
Next, a GitHub action will kick in once a `tag` is being pushed.
The GitHub action will run a build, and create a draft release on GitHub
that will contain:
1. The CHANGELOG.md contents for the last version
2. The `standalone-cli` artifacts attached to the drafted release
Once you are happy with the draft, you can publish the draft on GitHub.
This in turn will trigger another GitHub action that will publish the
packages to npm.
Whenever an insiders release or a normal release completes, we will also
trigger Tailwind Play, to update its dependencies to the latest version
of Tailwind CSS.
---
Note: some of the GitHub Action workflows still refer to the `next`
branch instead of the `main` branch. If we later today want to get a new
release out, we can merge `next` into `main` and update the workflows
accordingly.
---
This is hard to test, but I started from the existing release.yml file
and adjusted things accordingly. The biggest change is related to the
insiders version. If you look at this temporary
[commit](572dddfc33),
you can see that the publishing (dry-run) seems to work as expected:
<img width="1508" alt="image"
src="https://github.com/user-attachments/assets/c075e788-dcbc-4200-aa32-2b9a3c54d629"
/>
* 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>
* 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
* Add standalone-cli build for Windows ARM64
* Fix path to binary on windows
* Fix style
* Simplify Windows mapping in standalone CLI tests
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* remove unnecessary download links
GitHub already shows them in a table right below it.
* detach `npm run style` from `npm run test`
* decouple lint from test in workflows
Which means that we don't need to do the crazy linking in certain
workflows.
* hoist the `CI` environment variable
* create dedicated `lint` job
The `lint` tests will run against source files and should not be
dependant on a specific node version. Instead of running the `npm run
style` on every node version we use, we can and should only run it once.
* remove `prettier-plugin-tailwindcss`
As long as we use older versions of node/npm where we can't have
ourselves as a dependency, it is a bit of a mess to maintain properly
sorted html in tests.
Let's remove it for now until we have a better solution!
* rename `build-cli.yml` to `prepare-release.yml`
In other repo's we will also have a `prepare-release` so this makes it a
bit more consistent.
* use common CONSTANT_CASE for environment variables
* use `strategy` for defining the node version
* add script to get the release notes
* add release notes to release draft
* use CONSTANT_CASE for environment variables
* improve consistency for relase related scripts
