Simplify CI, make oxide engine the default #11281
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
+ drop testing against 3.3 branch (since this is stable only) + remove unnecessary CACHE_PREFIX
+ change release channel to just `insiders` instead of `oxide-insders`
This makes it consistent with the other job names
Currently commented out until we figure out how this will work exactly.
e418d93 to
a3a83de
Compare
cfdd0ce to
f93f7e2
Compare
adamwathan
added a commit
that referenced
this pull request
May 25, 2023
* 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>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR simplifies CI by making the oxide engine specific workflows the default workflows