* 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
* Don’t re-add files in the CLI watcher that are covered by dynamic patterns
They don’t have the same problem. As long as the parent directory is watched their add/change events will fire correctly
* Ignore raw events for files that don’t match the content files
* fixup
* Update changelog
* Fix CLI not watching atomically renamed files
Chokdar should take care of this itself but sometimes it doesn’t do so OR is otherwise very sensitive to timing problems
* Force chokidar to always check for atomic writes
* Handle repeated atomic saves by retrying file reads
* Update changelog
* Add support for postcss-import in watch mode
* Add regression test
* Extract shared logic
* restructure test a little bit
Instead of relying on a arbitrary setTimout value, let's wait for the
file to be created instead.
* update changelog
Co-authored-by: Adam Bergman <adam@fransvilhelm.com>
* ensure we can use `@import 'tailwindcss/...'` without node_modules
This is useful if you are using `npx tailwindcs ...` and to prevent
that postcss-import crashes on the tailwind specific imports which we
will replace anyway.
* update changelog
* add generate-types script
This script will generate the full list of core plugins, which will
allow you to get code completion for the `corePlugins` section.
It will also generate all the colors (and deprecated colors) which is
used in multiple places in the config.
* add types for the `tailwind.config.js` config file
* annotate stubs with a JSDoc pointing to the types
* add types to package.json
- Updated the files to make sure that the types are being published
- Add a `types` section in the `package.json`, otherwise your editor by
default will look for the `DefinitelyTyped` types which got me really
confused for a second.
- Added some scripts to make sure that the generation of types happens
when needed (before tests and before building). This way you never
ever have to think about generating them when working on Tailwind CSS
internals.
* re-export types top-level
Having a `colors.d.ts` next to the `colors.js` file allows us to type
the `colors.js` file and your editor will pickup the types from
`colors.d.ts`.
* also publish generated types
* update changelog
* enable TypeScript only when using `init --types` for now
* update tests to verify that `--types` works
* ensure content files are available in config
If you use the cli with the `--content` option, then we first resolve
the config (empty), then add the `content` to the config. The issue is
that this means that the content will be empty when you resolve it
initially. This results in a warning in your terminal.
Now, we will make sure to merge 2 configs if you have the `--content`
data passed. We will also make sure to override the final
`config.content.files` to whatever you passed in to make sure that this
is the same behaviour as before.
* update changelog
* use outputFile instead of direct writeFile
This is an improvement we introduced earlier but forgot this part.
* allow to pipe in data to the CLI
* add integration tests to validate piping to the CLI
* update changelog
* fix(cli): avoid write same output when no changes
* generalize outputFile
This function will check a cache, it will only write the file if:
- The modified timestamps changed since last time we wrote something.
This is useful to know if something changed by another tool or
manually without diffing the full file.
- The contents changed.
* further simplify checks
Turns out that reading files and comparing them is fairly fast and there
is no huge benefit over only using the Stats of the file and keeping
track of that information.
Thanks @kentcdodds!
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
* immediately take the `safelist` values into account
Currently we had to manually add them in the `setupTrackingContext`,
`setupWatchingContext` and the `cli`.
This was a bit cumbersome, because the `safelist` function (to resolve
regex patterns) was implemented on the context. This means that we had
to do something like this:
```js
let changedContent = []
let context = createContext(config, changedContent)
for (let content of context.safelist()) {
changedContent.push(content)
}
```
This just feels wrong in general, so now it is handled internally for
you which means that we can't mess it up anymore in those 3 spots.
* drop the dot from the extension
Our transformers and extractors are implemented for `html` for example.
However the `path.extname()` returns `.html`.
This isn't an issue by default, but it could be for with custom
extractors / transformers.
* normalize the configuration
* make shared cache local per extractor
* ensure we always have an `extension`
Defaults to `html`
* splitup custom-extractors test
* update old config structure to new structure
* ensure we validate the "old" structure, and warn if invalid
* add tests with "old" config, to ensure it keeps working
* add missing `content` object
* inline unnecessary function abstraction
* 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
Do not require NODE_ENV to be set to 'production' as well, as using
the --purge option in the CLI should be explicit enough.
Co-authored-by: Arnout Roemers <roemers@zorgdomein.nl>
* add tests for the --postcss option in the new CLI
* add `oneOf` ability to the `arg()` functionality
By default, `arg()` doesn't have a way to define multiple types. We want
the possibility of using `--postcss` (Boolean) or `--postcss
./custom-path.js`. But by default this is not possible.
This commit will allow us to do a few things, mainly:
- Keep the same API using the `{ type: oneOf(String, Boolean), description: '...' }`
- Keep the `--help` output similar
What we did behind the scenes is make sure to put the non recognized
flags in the `_` arguments list. This is possible by doing `permissive:
true`. We then manually parse those and resolve the correct value.
* ensure that we can use a custom `--postcss ./with-custom-path.js`
* fix --help output in tests
* add tests to ensure we can use `purge.safelist`
* implement the `purge.safelist` for strings
* proxy `purge.safelist` to `purge.options.safelist`
This allows us to have a similar API in `AOT` and `JIT` mode.
* only proxy `purge.safelist` to `purge.options.safelist` if
`purge.options.safelist` doesn't exists yet.
