From my experience with my canvas library, devs seem to want different types of documentation for different purposes:

1. Something that tells them what the library does: what problems it's gonna solve for them; how easy it is to work with; etc. Having something to play with is really useful here, for instance some "Getting started" code to (very quickly) show them the basics and let them play with the library. A set of "learn to" lessons tackling some interesting problems is good bonus documentation, alongside a good range of demo code.

2. Something that they can show to whoever controls which libraries they can use in the product they're working on, to help convince them to let the dev use the library. Usually involves some marketing copy and comparison charts - whatever A/B tested copy|crap floats the boat.

3. Some easy-to-use lookup reference stuff - what function do I have to invoke to get this specific thing done? Stuff that their coding environment doesn't reveal at the click of a button. This is where the LLM-focussed documentation comes in (I think), given the move to using code assistants: failing to (be able to) teach the models what the library can do (and how to best do it) can lead to bad code and wasted time, which reflects really badly on the library.