* use `defaults` for `browserslist`
+ some features that we require for Tailwind to work.
* simplify Lightning CSS features
Always transpile `Nesting`, never transpile `LogicalProperties`.
* bump caniuse-lite (`npx browserslist@latest --update-db`)
* reflect changes in the tests
* update changelog
* 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
* add failling test using array syntax without space delimiter
* add Rust test with candidates in array without spaces
* Fix JS arrays without spaces
* make the `oxideParser` the default
* sync feature flags with reality
* use better example in tests to be more real
* skip failing tests in the RegEx parser
* update changelog
* make `clippy` happy
---------
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* handle custom `transformer` and `extractor` implementations
Right now the Rust based parser can't work with custom `transfomers` or
`extractors`.
In a perfect world we can implement as many custom parsers/extractors in
Rust such that we don't need this at all. In an almost perfect world we
can pass the transformer and extractor to the Rust based parser and call
the callback functions to handle all of this. This is probably what we
are going to do in the future but this requires more work to make sure
that:
1. It works as expected
2. Doesn't result in (major) performance issues
Since it currently doesn't work with the Rust based parser, we can
implement a fix for this in the meantime before we reach the "perfect"
solution.
One solution to this problem is to check if we do have a custom
transformer or a custom extractor and if we do, then we can bail on the
Rust parser completely and just use the current regex based parser.
An alternative solution, the solution implemented here, is that we group
the `changedContent` into 2 buckets. The bucket where we rely on the
default transformer and extractor and a bucket where a custom
transformer or extractor is used.
Then, the bucket where we use the default transformer and extractor can
still rely on the way faster Rust based parser. For the other bucket we
fallback to the regex based parser.
The nice part about this is that we can use both parsers at the same
time, and the majority of the use cases should use the faster Rust based
parser.
* update changelog
* 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>
* Add `has-*` variants for `:has(...)` pseudo-class
* Update changelog
* Fix mistake in test
---------
Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
* remove `autoprefixer` dependency
This was only used in the CLI and we are not using it anymore. The
functionality of `autoprefixer` is baked into `lightningcss`.
* update changelog
* enable `--no-autoprefixer` test
* handle `--no-autoprefixer` using lightningcss
* bump default chrome version for lightningcss plugin
* handle `map` being nullable
* add `--no-autoprefixer` test including nesting
* set Chrome to version 111 as a default value
* resolve the output message when resolving the promise
* deprecate `--no-autoprefixer` for the CLI
* update changelog
* run PostCSS relative to test file
The PostCSS `from` was always set to the `tests/util/run` file with the
current test name as a query param to make it unique. However, that
results in issues with relative file paths because they are now relative
to this file instead of the actual test file.
Luckily, `expect.getState()` exposes the `testPath` value that points to
the current test file itself.
* add built in `@import` processing
+ additional features such that you can use `@tailwind` and `@config`
directives before the `@import` at rule which isn't normally allowed.
However "@tailwind" in a way is an `@import` and `@config` in a way is
a `@charset` which can be used before the `@import` at rule.
* drop partial normalizeTailwindDirectives when in the Oxide engine
This will now be handled by Tailwind from a higher level, so the core
doesn't have to worry about normalizing this anymore since it will
always be normalized right now.
* add `handleImportAtRules` to CLI
* update changelog
* scope `import processing` to the oxide engine
* update Changelog
* use direct comparison
We don't need the `startsWith` check anymore because the contents of the
comment will be the actual value we expect.
* resolve all _existing_ content paths
* pin `@napi-rs/cli`
* WIP: Log all resolved content files/globs
* only filter out raw changed content in non-auto mode
* skip parseCandidateFiles cache in `auto` mode
* improve algorithm of detecting content paths
1. Files in the root should be listed statically instead of using globs.
2. Files and folders in special known direct child folders should be
listed statically instead of using globs (e.g.: `public`). This is
because these special folders are often used to store generated AND
source files at the same time. Using globs could trigger infinite
loops because we are watching and acting upon dist files.
3. All file extensions found in the project, should be used in the globs
in addition to a known set of extensions.
4. Direct folders seen from the root, can use the glob syntax
`<root>/src/**/*.{...known-extensions}`
* inline wanted-extensions
Not 100% convinced yet, but seems cleaner so far.
* ensure writing an file also makes the parent folder(s)
* add integration tests for the auto content feature
* add pnpm and bun lock files
* Revert "inline wanted-extensions"
This reverts commit 879c1248524e84216125f4a24e0160b40736333a.
* sort binary-extensions and add lockb
* sort + add `lock` to ignored extensions
* drop `yarn.lock`, because lock extensions are already covered
* group template extensions
This will make it a bit easier to organize in the future.
* drop empty lines and commented lines from template-extensions
* skip the config path when resolving template files
The config file will automatically trigger a rebuild when this file is
changed. However, this should not be part of the template files because
that could cause additional css that's not being used.
* make `auto content` the default in the oxide engine
- In the oxide engine, the default `content: []` will be dropped from
the default configuration (config.simple.js, config.full.js).
- If you have `content: []` or `content: { files: [] }` then the auto
content feature won't be active. However if those arrays are empty a
warning will still be shown. Adding files/globs or dropping the
`content` section completely will enable auto content.
* only test the auto content integration test in the oxide engine
* set `content.files` to `auto` instead of using `auto: boolean`
This way we don't run into the issue where the `config.content.files` is
set and the `config.content.auto` is set to true.
* drop log
* ensure we validate the config in the CLI
* show experimental warning for automatic content detection
* use cached version of the getCandidateFiles instead of bypassing it
* use `is_empty()` shorthand
Thanks, Clippy!
* add test to ensure nested ignored folders are not scanned
* add `tempfile` for tests
* add auto content tests in Rust
* refactor auto content detection
This will also make sure that if we have (deeply) nested ignored
folders, then we won't use deeply nested globs (**/*.{js,html}) for the
parent(s) of the nested ignored folders but instead use a shallow glob
for each directory (*/*.{js,html}).
Then each sibling directory of the parent can use deeply nested globs
again except for the direct parent.
* use consistent comments
* ensure ignored static listed files are not present
* improve performance by ~30x
On a big test project this goes from ~6s to ~200ms
* improve performance by ~5x
We started with a ~6s duration
Then in the previous commit, we improved it by ~30x and it went down to
~200ms
Now with this change, it takes about ~40ms. That's another ~5x
improvement.
Or in total a ~150x improvement.
* ensure nested folders in `public/` are also explicitly listed
* add shortcut for normalizing files
This is only called once so won't do anything to the main performance of
Tailwind CSS. But always nice to make small performance improvements!
* run Rust tests in CI
* fix lint warnings
* update changelog
* Update CHANGELOG.md
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.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
* 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>
* Fix issues with some pseudo-elements
We’ve included pseudo elements for backdrop, marker, placeholder, and selection and they were all “jumpable” before we made changes in v3.3.2. Ideally they wouldn’t be because if they ever eventually have any interactivity that could become a problem.
* Update changelog
* bump `postcss-load-config` in the oxide engine
* bump `postcss-load-config` in the stable engine
* update changelog
* Switch to stable
* Update Node to v14
* Update to latest dependency versions
* Update test helper for new version of `rimraf`
Co-Authored-By: Jordan Pittman <jordan@cryptica.me>
* Downgrade `lightningcss` to `v1.18.0`
Co-Authored-By: Jordan Pittman <jordan@cryptica.me>
* Switch back to oxide
* Update Github actions from Node 12 to Node 14
* Update oxide dependencies
* Update stable dependencies
* Update `content-resolution` integration test dependencies
* Update `postcss-cli` integration test dependencies
* Update `rollup` integration test dependencies
* Update `rollup-sass` integration test dependencies
* Update `vite` integration test dependencies
* Update `webpack-5` integration test dependencies
* Update changelog
* Remove `color-name` dependency
* Replace `quick-lru` dependency with `@alloc/quick-lru`
* Replace `quick-lru` dependency with `@alloc/quick-lru` in stable
* Fix standalone CLI test
---------
Co-authored-by: Jonathan Reinink <jonathan@reinink.ca>
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* ensure we normalize the arbitrary modifiers
This applies the same rules as arbitrary values. The `_` can be used in
place of a space. If you _do_ want an underscore, you can escape it with
`\_` (`\\_` in JavaScript).
* update changelog
* ensure that last `]` doesn't stop the match
Given this input:
```html
<div class="[width:_calc(theme(spacing[5])_+_theme(spacing[5]))]"></div>
```
Then we would expect the match to be this:
```
[width:_calc(theme(spacing[5])_+_theme(spacing[5]))]
```
However, with the `?`, then it would stop and result in:
```
[width:_calc(theme(spacing[5])_+_theme(spacing[5]
```
Which makes it incomplete because the `))]` are missing at the end.
* update changelog
* replace `env.OXIDE` with global `__OXIDE__`
This will allow us to replace the `__OXIDE__` at build time, and fully
remove the branches from the final code so that there is not even any
reference to `@tailwindcss/oxide` on the stable engine.
* update changelog
* use `env.ENGINE` in integration tests
* drop oxide branching for the PostCSS plugin for now
This is currently a redirect to the same file, so doesn't hurt.
* Enable better dead-code elimination
* Update CLI tests
Fix indentation
* Fix indentation
---------
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* 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>
* WIP
* Move warning to validateConfig
This only happens in setupTrackingContext outside of resolveConfig
* Use original dynamic require approach in `validateConfig`
The important thing is that this happens in Node-land only. It is outside of `resolveConfig` which is public and importable into user projects. That is the scenario that breaks because of static import hoisting.
* Don’t reference process when it might be undefined
The `resolveConfig` dep path is public which should not reference process. However, we have some behavior that changes based on env vars so we need to conditionalize it instead.
* Update changelog
* Formatting
* More formatting
* Update changelog
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
Co-authored-by: Jonathan Reinink <jonathan@reinink.ca>
* drop `@tailwindcss/line-clamp` check
This won't work in places where `require` calls are hoisted so that
they become static imports. This means that in some projects this
`require` call was breaking the full application even though it was
intentionally put in a try/catch block...
* update changelog
* Revert prepare of v3.3
* Revert "Revert prepare of v3.3"
This reverts commit 14d5a0a7c6.
* update SafelistConfig type
I think this type was meant to be like this?
* format types
* update changelog
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
* Pull pseudo elements outside of `:is` and `:has` when using `@apply`
* Update changelog
* Refactor
* Update important selector handling for :is and :has
* fixup
* fixup
* trigger CI
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
* try to use `config.default` before using `config`
* update changelog
* add quick `SHOW_OUTPUT` toggle for integration tests
Setting this to `true` shows the output of the executed commands.
* add integration tests for `tailwind.config.ts` and `tailwind.config.js` with ESM syntax
* add gradient color stop positions
* update tests to include gradient position color stop reset values
* add dedicated color stop position tests
* use `%` sign in the name of the uility
* update changelog
* ensure `length` values and css variables work
* fix assumption when resolving dependencies
When resolving dependencies given a path, we are only interested
relative files from the current file. We are not interested in the
dependencies that are listed in your `package.json` and thus in your
`node_modules` folder.
We made the assumption that your imports have at least 3 characters.
This sort of makes sense because there will be a `.`, then the OS
separator like `/` and than a file name. E.g.: `./a` is the minimal
amount of characters.
This makes sense for `import` statements, but in the case of `require`,
it is totally valid to write `require('.')`. This will require the
current `index.{js,ts,mjs,cjs,...}` in the current directory.
Before this change, having a `require('.')` wouldn't crash, but the
dependency would not be marked as a module dependencies and therefore we
won't listen for file changes for that dependency.
* update changelog
* ensure we have no dependencies when `absoluteFilePath` is `null`
This happens in the CLI where we don't have a guaranteed `path` for the
config file. This can happen in practice if you use:
```console
npx tailwindcss --content ./index.html -o ./output.css
```
... and if you don't have a `tailwind.config.{js,ts,cjs,...}` in the
current directory.
* update changelog
