We try to avoid using any within our codebases since it typically causes a loss of type safety and can more easily lead to bugs. That's why we use the @typescript-eslint/no-explicit-any ESLint rule. Can you look into designing this without any?

I did and as I said: „We can make it a generic parameter, but it wouldn't bring any real benefit, just increase complexity and decrease flexibility.“ Using any is perfectly fine in this case, it does not cause a loss of type safety for the users of this hook.

I read what you wrote in your PR description; however, what you've stated is not true.

To demonstrate this, let's say a user of this hook needs to write a useEffect() hook with one of the item's ref objects. They might add this code:

useEffect(() => {
	// Do something
}, [itemProps[0].ref.current?.nonexistentProperty]);

Currently, if you simulate this by adding that code to the src/use-dropdown-menu.test.tsx file, this correctly throws a compile error:

The same useEffect() hook with your proposed changes gives no warning:

So using any in this case would cause a loss of type safety whenever a user of this package needs to work with a ref on one of the items.