This is a quick fix to an issue where the types for PluginsConfig don't
match those used in plugins like
[`@tailwindcss/container-queries`](https://github.com/tailwindlabs/tailwindcss-container-queries).
This was caught by TypeScript with [`exactOptionalPropertyTypes`](
https://www.typescriptlang.org/tsconfig/exactOptionalPropertyTypes.html)
enabled, where TypeScript checks if `undefined` can be supplied as a
value for optional types.
I felt that it made more sense to fix this here, as it makes the core
types more flexible, as opposed to each plugin needing to fix this
when/if they hit it.
---------
Co-authored-by: Philipp Spiess <[email protected]>
`boxShadow` accepts multiple shadows just like `dropShadow` does. This
patch fixes the TS typings to reflect that.
See demo showing that multiple shadows are supported (complete with it
incorrectly complaining that the config is bad) here:
https://play.tailwindcss.com/VHqWbbEIrz?file=config
---------
Co-authored-by: Philipp Spiess <[email protected]>
* Generate types: do not intersect with Config theme type when generating DefaultTheme
* Merge default theme in ResolvedConfig
* UnwrapResolvables on theme.extend as well
* Apply extend to overrides and default theme
* Omit extend from DefaultTheme
* Relax generic constraints, better generic variable names
* Fall back to ThemeConfig if key not in DefaultTheme
* Split out ThemeConfigCustomizable to avoid anys in ThemeConfigResolved
* Allow custom theme properties
* handle TypeScript error
* apply prettier formatting
* update changelog
* change type name
---------
Co-authored-by: Nikita Gaidakov <[email protected]>
Co-authored-by: Robin Malfait <[email protected]>
* Update config.d.ts, Make array members partial in Config
Instead of `Partial<Array<Thing>>` have `Array<Partial<Thing>>`
* simplify types further
* update changelog
---------
Co-authored-by: Robin Malfait <[email protected]>
* Revert prepare of v3.3
* Revert "Revert prepare of v3.3"
This reverts commit 14d5a0a7c6d457a9b73fa1a9aca6ed41c46b27ad.
* update SafelistConfig type
I think this type was meant to be like this?
* format types
* update changelog
---------
Co-authored-by: Robin Malfait <[email protected]>
* Revert "add caption-side utilities (#10470)"
This reverts commit 19f05892e9.
* Revert "Add support for configuring default `font-variation-settings` for a `font-family` (#10515)"
This reverts commit 314c1920d9.
* Revert "feat: add hyphens (#10071)"
This reverts commit 82709bed66.
* Revert "Add logical properties support for inline direction"
* Revert "Add `delay-0` and `duration-0` by default"
* Revert "Support using variables as arbitrary values without `var()`"
* Revert "Add `line-height` modifier support to `font-size` utilities"
* Add support for configuring default `font-variation-settings` for a `font-family`
* update changelog
---------
Co-authored-by: Nikolai Grushkovsky <[email protected]>
* 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 <[email protected]>
* 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
