Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove Bluebird #74

Closed
sdd opened this issue Jan 23, 2017 · 4 comments
Closed

Remove Bluebird #74

sdd opened this issue Jan 23, 2017 · 4 comments

Comments

@sdd
Copy link
Collaborator

sdd commented Jan 23, 2017

Although #58 shows as merged, the changes were not incorporated due to the ongoing discussion, and were reverted by a subsequent commit. Unfortunately merging #72 caused GitHub to mark #58 as merged and will not let me re-open that PR (sorry @scttcper!).

@sdd sdd mentioned this issue Jan 23, 2017
@sdd
Copy link
Collaborator Author

sdd commented Jan 23, 2017

My last comment on #58:

After thinking about it a bit more and looking into it, the SemVer spec itself states as point 1:

Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist strictly in documentation. However it is done, it should be precise and comprehensive.

Since our documentation and koa's documentation on the usage of middleware are as close as we come to having an explicit public API, we either consider that to be our public API or we aren't SemVer.

With this in mind, usage of koa-jwt that extends the library and depends upon using bluebird-only promise methods rather than using it as documented could be considered to not be using the public API. As such, we would not require a major version bump.

Thoughts?

@scttcper
Copy link
Contributor

The docs say a promise is returned. This is why I was surprised to find bluebird was brought in to wrap a single function. I don't see an issue bumping the major version to be safe. Really wish koa would go full on v2

@nfantone
Copy link
Member

I (kinda) agree on the "misusage" of the API argument. It's a case of "penalizing" not-so-good users. Personally, I wouldn't mind a minor bump for this. But since we cannot safe-guard against all breaking changes, I'd also include some comment on the docs, somewhere. Maybe on the README.md.

@cncolder
Copy link
Contributor

cncolder commented Mar 1, 2017

Koa@2.0.1 has released! It's time to face this issue. I think sindresorhus/pify is a good choice. It use native Promise default.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants