Skip to content
New issue

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

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

Already on GitHub? # to your account

Bluebird as peer dependency #169

Closed
wants to merge 1 commit into from
Closed

Bluebird as peer dependency #169

wants to merge 1 commit into from

Conversation

o0x2a
Copy link

@o0x2a o0x2a commented Dec 6, 2016

The Bluebird installation of the host package should be used if it's available, as the package consumer needs consistency in Promise behaviour across the application.

The Bluebird installation of the host package should be used if it's available, as the package consumer needs consistency in Promise behaviour across the application.
@coveralls
Copy link

coveralls commented Dec 6, 2016

Coverage Status

Coverage remained the same at 100.0% when pulling a7040e9 on code-guru:patch-1 into 1389cf7 on request:master.

2 similar comments
@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling a7040e9 on code-guru:patch-1 into 1389cf7 on request:master.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling a7040e9 on code-guru:patch-1 into 1389cf7 on request:master.

@analog-nico
Copy link
Member

Hi @Code-guru ! It of course makes sense to me to move Bluebird into the peerDependencies. However, such decision always has the disadvantage that first-time users have a harder time to install all packages. We should respect that unless of course there is a real necessity to make the change. What is your use case?

@o0x2a
Copy link
Author

o0x2a commented Dec 6, 2016

It completely makes sense to make it easier for all users.

Since I usually bluebird in most of my projects, I wanted to make sure a Promise object have always the same functionality and behaviour all over the application.

In case there is a bugfix or a new feature in bluebird, I can make sure they are available on the Promise return by request-promise.

This feature is not crucial, I suggest this change since you already define request package as peerDependency.

At work, I've seen few of my colleagues, although they're experience developers, however are skeptical (not yet grasp) about the promise-based flow-control. Asking them to start using bluebird may scare them :-)

@analog-nico
Copy link
Member

Mmh, I would say we leave it as it is and reevaluate if we should make the change once you or other people report more reasons for it.

I am not too happy with request being a peerDependency. I explained in #142 why I think this way. Unfortunately, I am not sure what a proper solution should be.

Btw, once bluebird@4 comes out I'll change ^3.4.1 to >=3.4.1 so you can stay up-to-date. And if you ever encounter difficulties because request-promise uses an older version of bluebird you can always use Bluebird.try(() => { return rp(...) }).then(...) as a workaround so your project is not blocked while we discuss how to resolve this.

Thanks for bringing this up!

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

Successfully merging this pull request may close these issues.

3 participants