* support `@apply` for classes outside of a `@layer`
* Add failing test for respecting source order
* sort rules when using `@apply`
The `layer` was not taken into account yet when we resolved the rules
from the applyCache. This is because we set the `classCache` to the
`matches` inside of the `generateRules` function. You can think of them
as "raw" rules I guess. However, it is later in that function that we
apply the `layerOrder` to the `sort`.
This does mean that when you `@apply font-bold text-red-500` that the
rules inside the `.target {}` will be in order of the "normal" css as
well.
Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
When you run `npm version`, it also tries to make a git commit and a git
tag. However, we are not doing anything with this and CI doesn't know
who the committer is.
This fails because we usually use node 14 or 16, which has a
package-lock.json version of `2`. However on node 12, this version is
`1`. This means that after an npm install the package-lock.json is
touched and thus `npm version` fails because git is in a dirty
directory.
Adding a `--force` is not ideal, but also not really an issue since the
only thing that could change is the package-lock.json and this is not
published to npm anyways.
* ensure we build before the tests
Our tests require that for now. Will probably improve this in the
future.
* improve insiders version name
This will make it consistent with previously published versions.
Co-Authored-By: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
Co-authored-by: Jonathan Reinink <jonathan@reinink.ca>
Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
* simplify `negateValue`
Co-authored-by: Brad Cornes <bradlc41@gmail.com>
* ensure we have the exact same behaviour
* Simplify/loosen regex to be more future-proof
Co-authored-by: Brad Cornes <bradlc41@gmail.com>
Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
* add tests for the plugin API
* make plugin invocation optional
It could be that an object has been passed as a plugin, in that case we
will use the `handler` function from the object. If it doesn't exist,
then we will only take the `config` section out of it.
* move `./tests/jit` to `./tests`
* make tests consistent
Abstracted a `run` function and some syntax highlighting helpers for
`html`, `css` and `javascript`.
* chore: remove duplicate prettier.config.js settings from .eslintrc.json
* chore: remove unnecessary brackets now that "prettier/prettier" rule is no longer an array -- this a purely cosmetic change
* make `jit` mode the default when no mode is specified
* unify JIT and AOT codepaths
* ensure `Object.entries` on undefined doesn't break
It could be that sometimes you don't have values in your config (e.g.: `presets: []`), this in turn will break some plugins where we assume we have a value.
* drop AOT specific tests
These tests are all covered by JIT mode already and were AOT specific.
* simplify tests, and add a few
Some of the tests were written for AOT specifically, some were missing. We also updated the way we write those tests, essentially making Tailwind a blackbox, by testing against the final output.
Now that JIT mode is the default, this is super fast because we only generate what is used, instead of partially testing in a 3MB file or building it all, then purging.
* add some todo's to make sure we warn in a few cases
* make `darkMode: 'media'`, the default
This also includes moving dark mode tests to its own dedicated file.
* remove PostCSS 7 compat mode
* update CLI to be JIT-first
* fix integration tests
This is not a _real_ fix, but it does solve the broken test for now.
* warn when using @responsive or @variants
* remove the JIT preview warning
* remove AOT-only code paths
* remove all `mode: 'jit'` blocks
Also remove `variants: {}` since they are not useful in `JIT` mode
anymore.
* drop unused dependencies
* rename `purge` to `content`
* remove static CDN builds
* mark `--purge` as deprecated in the CLI
This will still work, but a warning will be printed and it won't show up
in the `--help` output.
* cleanup nesting plugin
We don't have to duplicate it anymore since there is no PostCSS 7
version anymore.
* make sure integration tests run in band
* cleanup folder structure
* make sure nesting folder is available
* simplify resolving of purge/content information
The trackedModified call in the tracking logic has a bug that
incorrectly removes `null` from pathnames
Currently:
```
let pathname = parsed.href.replace(parsed.hash, '').replace(parsed.search, '')
```
Where if `parsed.hash` or `parsed.search` are missing (which is
mostly the case for FS files), the value is null
eg `{ hash: null, search: null}`
- In which case, we essentially trim `null`
converting `/mypath/nulldir/file.js` -> `/mypath/dir/filejs` and
breaking builds (see #4920 ).
Fix checks if `hash` or `search` are set before replacing them
Fixes#4920
* update (old) incorrect snapshots
The version changed, so it is save to update these.
* add `shadow` so that we can test `@tailwind base`
We were only using `font-bold`, but that doesn't require any base rules.
We try to only inject rules that are required, even for `base` related
rules.
Adding `shadow` will ensure that we can test that `base` rules have been
added.
We applied the same treatment for the sanity tests, where we ignore the
first line (the tailwind header).
An odd issue I have found is that diffing of big css files is _very_
slow. When te tests pass, then the first test takes `3302 ms`, however,
when it fails it takes `477482 ms` on my machine. That's almost 8
minutes.
