v2.0.0 promisification changes
Closed this issue · 6 comments
from gitter:
@Rush and I have been discussing breaking API changes for the v2 release, including removing the current promise api (wrapping all methods in Async variants) in favor of one of two options:
- promisifying such that all methods can either take a nodeback and support the existing async behavior on normal methods (e.g. Hypervisor.connect), and returning a Promise if no callback is specified
- going with a completely Promise-based API, and dropping support for the old callback form - optionally warning users if they are passing a callback and expecting that to work
It would be great to hear if any of you have opinions on the issue
I'm ok with either, and would lean towards one or the other based on effort.
@Rush actually did a little napkin implementation when we were talking about it that supports callbacks and promises, so the effort is pretty minimal either way - it's more an issue of preference afaict. I feel like considering we attempt to follow semver, now is the time to discuss API breaks etc
I see, I think it is nice to be backwards compatible, especially, since we don't really know how many people is using the library. However, based on the NPM stats, it seems very few are.
I think having the missing callback trigger promise creation is great, so that either option is available. Very little overhead.
The NPM stats are probably low because this is a very niche product, how many people are writing tools in this space? Myself, I'm no longer in the job I was using this in :)
Hello, I only use the Promisified API (through GraphQL schema/resolvers), but I feel supporting both callbacks and promises is the best way to do.