* 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
* convert the `matchVariant` to look more like `addVariant`
With the biggest difference that the `matchVariant` will have a callback
function that receives the current value of the variant.
* use object as argument for `matchVariant` callback
This will allow us to add more properties in the future if needed
without breaking changes.
- This is a breaking change: `(value) => ...` -> `({ value, other }) => ...`
- This is **not** a breaking change: `({ value }) => ...` -> `({ value, other }) => ...`
* add types for `matchVariant`
* allow for arbitrary configuration in the `theme` section
This is useful for third party plugins otherwise you will get an error.
* WIP: `theme()` utility function code completion
This will give you code completion in the `theme()` function. The reason
it is still a WIP is that this only works with the default config right
now and not 100% sure if it is possible to define generics in JSDoc.
The idea would be to:
- Provide types from the default config
- Provide types from the custom config (e.g.: 3rd party plugin)
- Override default config types with the overrides of the user's config
Right now this only provides types for the defaultConfig which might
result in dropping all of this in favor of a much simpler:
```ts
theme<D = any>(path: string, defaultValue: D) => D
```
But this sadly doesn't give you "nice" auto completion. However, the
default might be good enough if we don't error on for example
`theme('customPlugin')` which is currently not the case.
* update changelog
* undo all `theme` types, and type it as `theme(path: string): any`
Since currently we don't want to investigate time to make the code
completion *perfect* (because it might be even impossible to do it
properly due to resolving of overrides, extend and deeply nested presets)
For now we will provide a way simpler type, which is better than
incorrect types. So far we only had types for the default config theme
*only*.
`Partial` is only 1 level deep. We don't want it to be recursively deep,
that's for the plugin itself to decide. But the parts under `theme`
should all be optional.
In my testing, I was publishing using a node 16 install, but on CI we
are using Node 12. It seems that the NPM that shipped with Node 12
ignores all files for publishing if they are mentioned in `.gitignore`
which I could reproduce locally.
Doing a bit of testing, I used this solution which I think we also used
in v2 when generating `dist/` files. The `npm publish --dry-run` now
_does_ include the generated types as well and they are still ignored
for version control.
* 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
