This ensures all imported types are using the `type` keyword.

Will be used in the new and existing components.

Right now Next.js does barrel file optimization and re-writing imports
to a real path in the `dist` folder. Most of those rewrites don't
actually exist because they have an assumption:

```js
import { FooBar } from '@headlessui/react'
```

is rewritten as:
```js
import { FooBar } from '@headlessui/react/dist/components/foo-bar/foo-bar'
```

This script will make sure these paths exist...

This hook has a default implementation when comparing objects. If the
object contains an `id`, then we will compare the objects by their
`id`'s without the user of the library needing to specify `by="id"`.

If the objects don't have an `id` prop, then the default is still to
compare by reference (unless specicified otherwise).

…ed components

…(singular)

This is so that we can be consistent with the other components.

This is a more complex version of a soon to be exported `mergeProps`
that we will be using in our components.

These are the ones being exposed inside `data-headlessui-state="..."`

A slot with `{active,focus,hover}` will be exposed as:
```html
<span data-headlessui-state="active focus hover"></span>
```

But also as boolean attributes:
```html
<span data-active data-focus data-hover></span>
```

…rward them to the component inside the `Fragment`

This is internal code, and the public API is not influenced by this
`:any`. It does make TypeScript happy.

This will help us to merge props, when event handlers are available they
will be merged by wrapping them in a function such that both (or more)
event handlers are called for the same `event`.

… at the end

Because `window.pageYOffset` is deprecated.

These components use hooks that won't work in server components and you
will receive an error otherwise.

Currently this one is not ready yet, so its not publicly exposed yet.

This one adds a component to render (hidden) inputs for native form
support. It also ensures that form fields can be hoisted to the end of
the nearest `Field`. If the components are not inside a `Field` they
will be rendered in place.

This only makes sense if anything inside the current element receives
focus, which is not the case for `input`, `select`, `textarea` or
`Radio/RadioOption`.

+ Track whether the button moved or not when disabling such that we can
  disable the transitions earlier.

These playgrounds are mainly test playgrounds. Lower priority for now,
we will get back to them.