chore(deps): upgrade deps and use ^
#93
Conversation
I've long held that locking down deps to a specific version was a good idea. But now I'm thinking that it's not worth the cost (also it doesn't really take care of transitive deps anyway). I've noticed build breakages recently. I believe that this will fix it. Maybe...
kentcdodds
assigned nkbt, rowanoulton, osdevisnot, martellaj, sxn, jisaacks, giladgo, gunnx and tleunen
There was a problem hiding this comment.
lgtm if build passes.
Yeah. I also think the same way. Especially with the yarn lock or npm shrinkwrap, locking the versions are not really necessary.
Also, with a greenkeeper setup, it's a bit easier to see when something's wrong in a dependency and requires hot patch/lock
|
Same with me: I'm ok with the change if it helps with the builds :-) I see the build's failed again though. 🐼 |
|
Yeah... :/ Why is bluebird required again? |
|
I have no idea what's going on here. I've been able to reproduce it locally a few times, but it's pretty inconsistent. I'm going to go ahead and merge this. Note that if #94 is merged, this wont matter anymore because the failing test will be removed ;-) |
|
Oh, also, I can't remember whether this package was guaranteed to work on Node 0.12.x but I think that's why I used bluebird. We can probably drop support in the next major version (which is definitely going to happen if #94 is merged). |
|
Oh, and I did set up greenkeeper. I've tried it before and it was too noisy, but we'll try it again and see how we feel about it :) |
What: chore(deps): upgrade deps and use
^Why: I've noticed build breakages recently. I believe that this will fix it. Maybe...
How: By hand mostly...
I've long held that locking down deps to a specific version was a good
idea. But now I'm thinking that it's not worth the cost (also it doesn't
really take care of transitive deps anyway).