* feat(preflight): simplify sans-serif font stack
`-apple-system` and `BlinkMacSystemFont` were historically needed for
IE11 and chakra-based Edge (The one that wasn't chromium-based).
https://caniuse.com/font-family-system-ui has more details around it.
* further simplify `font-family`
* update tests
* update changelog
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
* always prepend the Tailwind License
Even when you are not using preflight.
* drop the Tailwind License from the preflight plugin
* drop the license in the tests
This allows us to focus on the actual generated CSS without the license.
The license also includes the version number which we would have to
update every time we release a new version.
* update the source maps snapshots
* always prepend the license when using the CLI
* update Tailwind CLI integration test
* exclude `Features.LogicalProperties` lightningcss feature
We don't want this to automatically apply since we have dedicated
logical property based utilities already.
We also have a feature flag to toggle some utilities to make use of
logical property based ones.
This feature should be opt-in to prevent backwards compatibility (e.g.:
RTL sites that _did_ use a mr-4 explicitly).
* update default browserslist
* explicitly include/exclude Lightning CSS features
* update tests based on new browserslist and include/exclude features from Lightning CSS
* update integration tests
* prefer user browserslist, fallback to built-in browserslist
* always include Nesting
If a custom browserslist config is used, then we don't explicitly set
the include/exclude features from Lightning CSS (except for nesting, we
always want to process nesting)
* ensure to fallback to the current working directory
* update changelog
* bump `lightningcss`
* allow for non-standard selector combinators such as `::deep`
* just use Prettier when comparing CSS results
We were using 2 different engines where the stable one was not using
Lightning CSS and the Oxide one was using Lightning CSS.
To ensure that we didn't have to rewrite every single test expectation,
the `toMatchFormattedCss` parsed both the actual and expected value
using Lightning CSS (to make the result similar), then it used Prettier
to make it... pretty.
Right now we _only_ use Lightning CSS, which means that we can drop the
additional lightningcss format step and just use Prettier on both the
actual and expected values.
Pretty also only prettifies the CSS, it doesn't rewrite it. E.g.:
`@media (min-width: 768px)` will not be optimized to `@media (width >=
768px)`, that's something that Lightning CSS does for us.
This will require some changes in our test output, but it will be
consistent afterwards because there won't be hidden transformation steps
anymore. Because up until now it could be that the actual result was
`color: black` but the tests showed `color: #000` (because it is
shorter).
This change will reflect reality.
* update tests based on previous commit
* only use `toMatchFormattedCss` instead of `toMatchCss`
They both do the exact same thing right now. While `toMatchCss` is
shorter, `toMatchFormattedCss` makes a bit more sense since we are
comparing the Prettier results.
* update integration tests
* only try to pretty print `err.source` if it exists
* fix small typo
* drop unnecessary path resolving
* add `from` and `to` to `run` test helper
* enable all source map tests
* ensure source maps are generated properly
* update annotation values in tests
* handle `map: true`
* add test for `map: { inline: true }`
* force Lightning CSS to handle an inline source map
* base64 encode the test name
This will get rid of special characters that can cause issues /
confusion when debugging tests.
* ensure utilities and components with variants are pointing to the correct source
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* update changelog
---------
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* 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>
* Refactor
* Don’t resolve functions for anything not using theme or screen
* Normalize math operators inside calc when handling functions
* Inline postcss-value-parser
* Treat all functions the same as calc
* Remove workaround for calc + operators without spaces
* Remove `postcss-value-parser` dependency
* Update lockfile
* Update sourcemaps
* Update changelog
* Update `value-parser` formatting
* Stop prettier from complaining
* disable useragent styling for dialog
* nits
* Update src/css/preflight.css
* Simplify dialog reset
We don’t want to reset everything here. Just the padding should be enough.
* Update test
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* Make font settings propagate into buttons, inputs, etc.
* update source-maps test due to preflight change
* update changelog
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
* Revert "add caption-side utilities (#10470)"
This reverts commit f395cc4ae5.
* Revert "Add support for configuring default `font-variation-settings` for a `font-family` (#10515)"
This reverts commit 8bd2846b5b.
* Revert "feat: add hyphens (#10071)"
This reverts commit f58a43fd75.
* Revert "Add logical properties support for inline direction"
* Revert "Add `delay-0` and `duration-0` by default"
* Revert "Support using variables as arbitrary values without `var()`"
* Revert "Add `line-height` modifier support to `font-size` utilities"
* Add support for configuring default `font-variation-settings` for a `font-family`
* update changelog
---------
Co-authored-by: Nikolai Grushkovsky <n@ngrushkovsky.com>
* bump lightningcss
* use `lightningcss` in the main PostCss Plugin
* use lightningcss in our custom matchers
Now that we are using `lightningcss` and nesting in the new `oxide`
engine, the generated output _will_ be different in the majority of test
cases.
Using a combination of `prettier` and `lightningcss` will make the
output consistent.
The moment we are fully using the `oxide` engine, we can drop
`lightningcss` or `prettier` again to improve the performance of the
tests.
* update tests to apply `lightningcss` related changes
* update changelog
* add `lightningcss` and `browserslist` as dev dependencies to stable package.json
* only use `lightningcss` in tests (without prettier)
We will only fallback to prettier if lightningcss fails somehow.
* apply side effect chagnes due to only using lightningcss for tests
* make CI happy (integration tests)
Apply changes to integration tests now that we are using lightningcss
* transform `lightningcss` for Node 12 when running tests
* run prettier on failing tests for `toMatchFormattedCss`
This will result in better diffs because diffs are typically per block
and/or per line. But lightningcss will simplify certain selectors and
the diff won't be as clear.
We will only apply the prettier formatting for failing tests in the diff
view so that diffs are cleaner and we don't pay for the additional
prettier calls when tests pass.
* Run test suite against both engines
* make eslint happy
* only run `stable` tests on Node 12
* use normal expectation instead of snapshot file
When we run the tests only against `stable` (for node 12), then the
snapshots exists for the `Oxide` build. They are marked as `obsolete`
and will cause the `npm run test` script to fail. Sadly.
Inlined them for now, but ideally we make those tests more blackbox-y so
that we test that we get source maps and that we can map the sourcemap
back to the input files (without looking at the actual annotations).
* properly indent inline css
Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
* Preserve source maps for `@apply`
* Overwrite the source for all cloned descendants
* Preserve source maps when expanding defaults
* Verify that source maps are correctly generated
* Update changelog
