Robin MalfaitandGitHub 668248e854 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
2023-01-13 12:22:00 +01:00
2023-01-13 12:22:00 +01:00
2023-01-04 11:53:07 +01:00
2023-01-13 12:22:00 +01:00
2023-01-13 12:22:00 +01:00
2022-02-05 15:22:47 -05:00
2022-12-19 10:44:47 +01:00

Tailwind CSS

A utility-first CSS framework for rapidly building custom user interfaces.

Build Status Total Downloads Latest Release License


Documentation

For full documentation, visit tailwindcss.com.

Community

For help, discussion about best practices, or any other conversation that would benefit from being searchable:

Discuss Tailwind CSS on GitHub

For casual chit-chat with others using the framework:

Join the Tailwind CSS Discord Server

Contributing

If you're interested in contributing to Tailwind CSS, please read our contributing docs before submitting a pull request.

S
Description
A utility-first CSS framework for rapid UI development.
Readme MIT
112 MiB
Languages
TypeScript 81.9%
Rust 15.7%
JavaScript 0.8%
CSS 0.6%
HTML 0.6%
Other 0.4%