This PR bumps the repo to pnpm v11 (from v9).
I kept running into weird Windows specific issues for the integration
tests due to some shims but they all pass right now.
Bumping to pnpm v11 also meant that everything is driven by a
`pnpm-workspace.yaml` file, and changes applied via the `pnpm` field in
the `package.json` don't work anymore.
This also moved the `node-linker` setup that was defined in the `.npmrc`
file for the wasm oxide build into the `pnpm-workspace.yaml` file.
Ideally this is scoped to just this package, but I couldn't get that to
work, so it's applied to all packages right now.
[ci-all]
This PR improves GitHub workflows by making sure that:
- Uesed actions are pinned
- We don't persist credentials
- Remove caches from release workflows
- Prevent template expansion when using `env.…` in `run` blocks
- Use the `gh release` instead of `softprops/action-gh-release`
This PR improves the workflows a bit more by:
1. Making sure that we always use `pnpm install` with a frozen lockfile
2. Cleanup permissions
3. By not caching `~/.cargo/bin/`
## Test plan
1. Every test should still pass
[ci-all]
This PR updates the CI workflows related to NAPI-RS. So far, we've been
using a custom ghcr.io based image, but these run on Node v18.
With this PR, I created a new project using `napi new`, with GitHub
Actions workflow setup. Then essentially ported the changes from that
new project to this project (as minimal as possible).
The main goal was to be able to bump NAPI-RS related dependencies _and_
get an insiders release out. The images used in these CI jobs were
blockers to get an actual (insiders) release out.
## Test plan
1. CI still passes
2. Added a dry-run on the prepare release workflow to test that we got
through the entire workflow without issues
## Summary
This PR updates outdated GitHub Action versions by migrating
`actions/download-artifact` from `v6` to `v7` in the following
workflows:
- `.github/workflows/prepare-release.yml`
- `.github/workflows/release.yml`
- `.github/workflows/release-insiders.yml`
## Test plan
The changes will be tested in the CI pipeline of the pull request.
[×] Summary
[×] Test plan
All bumped `actions/*` for GitHub Workflows require Node 24 right now.
We were relying on Node 20, but that's in maintenance mode until April.
Node 24 is the current Active LTS version.
When using NAPI to build for release purposes, it relies on `inquirer`,
which relies on `@inquirer/core` which relies on a modern Node version
to support `import { styleText } from 'node:util'`
We want to still make sure that CI / Integration Tests pass on Node v20
(which we currently do), so just bumping the prepare-release.yml,
release-insiders.yml and release.yml workflows.
If this isn't enough, I'll properly drop the `@napi-rs/cli` version or
force an `inquirer`/`@inquirer/core` version. Let's try this first.
Closes#17448Closes#13133
This PR adds an a new Oxide target for `wasm32-wasip1-threads`:
`@tailwindcss/oxide-wasm32-wasi`. The goal of this is to enable more
environments to run Oxide, including (but not limited to) StackBlitz.
We're making use of `napi-rs`'s upcoming v3 features to simplify the
setup here, meaning `napi-rs` will configure the WASM target and create
an npm package that works across Node and browser environments.
## MacOS AArch64 issues
While setting up an integration test for the new WASM target, I ran into
an issue where FS reads where not terminating on macOS. After some
research I found this to be a limitation of the Node.js container
interface right now, see: https://github.com/nodejs/node/issues/47193
### Windows issues
We also found that the Node.js wasi container does not properly support
Windows: https://github.com/nodejs/uvwasi/issues/11
For now we, it's probably best for MacOS AArch64 users and Windows users
to use the native modules instead.
## Test plan
The `@tailwindcss/oxide-wasm32-wasi` npm package can be built locally
via `pnpm build` and then run with the Oxide API. A usage example can be
taken from the newly added integration test.
Furthermore this was tested to work as a polyfill on StackBlitz:
https://stackblitz.com/edit/vitejs-vite-uks3gt5p
[ci-all]
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
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:
3672361307
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
2022-10-19 15:52:39 +02:00
Renamed from .github/workflows/build-cli.yml (Browse further)
