Before we were just checking if the `modifiers` option is `any` or an
object, without actually checking that in case it is an object, the
value actually existed.
* remove unnecessary download links
GitHub already shows them in a table right below it.
* detach `npm run style` from `npm run test`
* decouple lint from test in workflows
Which means that we don't need to do the crazy linking in certain
workflows.
* hoist the `CI` environment variable
* create dedicated `lint` job
The `lint` tests will run against source files and should not be
dependant on a specific node version. Instead of running the `npm run
style` on every node version we use, we can and should only run it once.
* remove `prettier-plugin-tailwindcss`
As long as we use older versions of node/npm where we can't have
ourselves as a dependency, it is a bit of a mess to maintain properly
sorted html in tests.
Let's remove it for now until we have a better solution!
* Record and watch PostCSS dependencies in the CLI
* ensure `changedContent` gets cleared
Otherwise this list gets bigger and bigger, not only that there is a
subtle bug. The moment you save a `.css` file we want to create a new
context and start from scratch. However, since the list was never
cleared, it meant that every subsequent save to *any* file (not only
config / css files) creates a new context...
By clearing the least we should work around this problem.
* add test that verifies an odd bug
The story goes like this:
1. add `underline` to html file
-> css contains `underline` rule
2. add `font-bold` to html file
-> css contains `underline` and `font-bold`
3. remove `underline` from html file
-> css still contains `underline` and `font-bold` for performance reasons
4. Save a css file (! RED FLAG)
-> css contains `font-bold` because we started from scratch
5. add `underline` to html file
-> css contains `underline` and `font-bold`
6. remove `underline` from html file
-> css only contains `font-bold`... (UH OH)
This is because the moment we did step 4, every single save in any file created a new context. Every. Single. Time.
* use a property that doesn't require `autoprefixer`
* update changelog
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* rename `build-cli.yml` to `prepare-release.yml`
In other repo's we will also have a `prepare-release` so this makes it a
bit more consistent.
* use common CONSTANT_CASE for environment variables
* use `strategy` for defining the node version
* add script to get the release notes
* add release notes to release draft
* use CONSTANT_CASE for environment variables
* improve consistency for relase related scripts
This means that if you define your `matchVariant` as:
```js
matchVariant('foo', (value) => '.foo-${value} &')
```
Then you can't use `foo:underline`, if you want to be able to use
`foo:underline` then you have to define a `DEFAULT` value:
```js
matchVariant('foo', (value) => '.foo-${value} &', {
values: {
DEFAULT: 'bar'
}
})
```
Now `foo:underline` will generate `.foo-bar &` as a selector!
* 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>