* update changelog
* ensure `--content` is taken into account
* cleanup tests
- Use `rm` instead of deprecated `rmdir`
- Type the returnType correctly
* use a file not included in `content` of your tailwind.config.js file
* add `context.getVariants`
* use `modifier` instead of `label`
* handle `modifySelectors` version
* use reference
* reverse engineer manual format strings if container was touched
* use new positional API for `matchVariant`
* update changelog
* calculate tag for the release
This is based on the name we use in the version e.g.: `3.2.0-beta.2`. If
no name can be found in the version, we will default to `latest`
* ignore node_modules caching for now
* Add data variant
* Update CHANGELOG.md
Co-authored-by: Jonathan Reinink <jonathan@reinink.ca>
Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
* Rename test variants
* Allow internally negating screens
* Refactor
* Add min/max screen variants
* wip
* Update changelog
* Update tests
* Sort list of variants properly
Technically each test isn’t 100% sorted right in isolation because prettier decisions are basically project-wide. This is close enough though.
* Update tests
* Change `matchVariant` API to use positional arguments
* Fix CS
wip
* Change match variant wrap modifier in an object
Needed for compat w/ some group and peer plugins
* Add modifier support to matchUtilities
* refactor
* Hoist utility modifier splitting
* Rename fn
* refactor
* Add support for generic utility modifiers
* Fix CS
* wip
* update types
* Warn when using modifiers without the option
* Allow modifiers to be a config object
* Make sure we can return null from matchUtilities to omit rules
* Feature flag generalized modifiers
We’re putting a flag for modifiers in front of matchVariant and matchUtilities
* cleanup
* Update changelog
* Properly flag variants using modifiers
* Fix test
* setup for container queries
* remove container query implementation itself
This will be moved to its own plugin.
* update changelog
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* Make `Config` completely optional for plugins
Right now the `Config` type requires a `content` key. However, for plugins, this should be completely optional. There’s little reason for a plugin to override content. All other keys are already optional by virtue of using `Partial<…>` so we’ll do the same for the `Config` type used by plugins.
* Update changelog
* add ability to add a `label`
This could be used for named groups or named container queries in the
future.
* expose `container` to `matchVariant`
Ideally we don't have to do this. But since we will be implementing
`group` and `peer` using the `matchVariant` API, we do require it for
the `visited` state.
* implement `group` and `peer` using the `matchVariant` API
* remove feature flag for `matchVariant`
* update changelog
* Improve type checking for formal syntax
* Add test
* Change order of test class name
* fix failing tests
* prefer `position` over `size` for backwards compatibility reasons
Previously `bg-[10px_10%]` generated `background-position: 10px 10%` before we introduced the fallback plugins.
Therefore we should prefer `position` over `size` as the default for backwards compatibility.
* update changelog
* ensure correct order
Thanks Prettier!
* update changelog
Co-authored-by: lzt1008 <lzt1008@live.com>
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
Co-authored-by: liangzhengtai <liangzhengtai_i@didiglobal.com>
* use test with non-any type plugin
* choose backgroundSize over backgroundPosition
Ensure that `backgroundColor` can take any value
* add tests to verify fallback plugins
* implement fallback plugins
Whenever an arbitrary value results in css from multiple plugins we
first try to resolve a falback plugin.
The fallback mechanism works like this:
- If A has type `any` and B has type `color`, then B should win.
> This is because `A` will match *anything*, but the more precise type
should win instead. E.g.: `backgroundColor` has the type `any` so
`bg-[100px_200px]` would match both the `backgroundColor` and
`backgroundSize` but `backgroundSize` matched because of a specific
type and not because of the `any` type.
- If A has type `length` and B has type `[length, { disambiguate: true }]`, then B should win.
> This is because `B` marked the `length` as the plugin that should
win in case a clash happens.
* Add any type to a handful of plugins
Needs tests tho
* Add any type to `border-{x,y,t,r,b,l}` plugins
* Add test for any type
* Split on multiple lines
* fixup
* add tests for implicit `any` types
* rename `disambiguate` to `preferOnConflict`
* update tests to reflect `any` types a bit better
* update changelog
* annotate any-type test with a bit more information
Just for future debugging reasons!
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* support `sort` function in `matchVariant`
This will ensure that we can sort arbitrary variant values (and
hardcoded values) to ensure the order.
* update changelog
* Update lockfile
* Tweak formatting
* Refactor content path parsing
* Allow resolving content paths relative to the config file
* Include resolved symlinks as additional content paths
* Update changelog
* Work on suite of tests for content resolution
* reformat integration test list
* Move content resolution tests to integration
* Update future and experimental types
* ✨ Add `word-break: keep-all` with `keep-all`
ref. https://developer.mozilla.org/en-US/docs/Web/CSS/word-break
`whitespace-nowrap` and `word-break: keep-all` behave differently in different browsers.
Demo: https://jsfiddle.net/h1aj6nvy/
There is a difference between Firefox and Google chrome.
* Rename `keep-all` to `break-keep`
Co-authored-by: Jonathan Reinink <jonathan@reinink.ca>
* ignored `undefined` and `null` value values for intellisense
We are not completely ignoring "all" falsey values, because then we
would get rid of `0` values (e.g.: `p-0`) which is not what we want.
* update changelog
