I’m not completely interested in defending everything I stated, because it’s all true, but I’ll give one go at it.
Yes it is a typo. These are twitch documentation docs. Not a library that wraps twitch. Twitches library is Twitch.ext, not twitch.ext. There’s no real argument to had here. Everywhere else in the docs it uses Twitch, not twitch. Any doc writer in the world would recognize this as a typo, as it is unequivocally incorrect of someone using the twitch library, which the documentation is documenting. Not a theoretical wrapper library.
For the isBitsEnabled, actually, your statement is incorrect. As I quote in the documentation. It says, if the context supports bits then getProducts() promise will be resolved, otherwise rejected. The context does not support bits, and the getProducts() promise was resolved, not rejected. Also, the reference guide should be the universal place for a person to get their documentation. Not scour for extra documents. The documentation reference is missing the isBitsEnabled section. At minimum it should be listed under useBits() as a warning to not invoke unless isBitsEnabled is true.
Furthermore, the useBits() is throwing an exception and not calling either the success or failure events. So this puts the application in a BROKEN state, waiting for a purchase to finish. Lets say someone wants to have it in a modal, and the modal goes away. Now they also have to add an arbitrary timer to detect when twitch fails to even do what it says it will do. The library is inconsistent. It should be capturing errors and passing it to the failure event, like every other javascript library. It’s expected behavior and currently it’s behaving unexpectedly.