And if you are using npm & bower in the same project then this other issue is a show stopper https://github.com/yarnpkg/yarn/issues/616

Out of curiosity, why use npm and bower in the same project?

Not op but I'll chime in. My team uses npm for our build tools and bower for our frontend libraries (moment, chats, lodash, etc). Our re-write only uses npm but at the time (and possibly even now) there were frontend libraries that only provide bower packages and bower seemed like the right tool for the job anyways.

It doesn't sound ideal having two tools that do pretty much the same thing, you are just adding a potential extra point of failure. Migrating from bower to npm is incredibly easy.

I remember wondering this same thing myself when Bower was the the new hotness.

"Don't I already have a tool that does exactly this?"

How would you migrate libraries that are only on bower, not npm?

How many of those are a) left and b) still maintained?

If there are still any in 2016 it's a good sign they are not begin actively maintained

Yeah I wouldn't use it in production until it becomes more stable. However the team behind it seems to iterate really fast. Look at the issues fixed between public release and 0.16[0], which is only 7 days.

[0]: https://github.com/yarnpkg/yarn/releases/tag/v0.16.0

I've been using it in production for a large app for the past week and it's been great. CI is faster, deploying is faster and dev is faster.

Likewise, can't wait for yarn to finish its growing pains, until then it's still npm.

It looks like they want to just eat bower. Tbh, if webpack or browserify can eat a tooling & dev stack, and yarn can eat bower and do package management, it would be a nice workflow.

I wouldn't want 1 tool to rule them all, but a single tooling/dev/task kit and a single dependency/pckg manager would be nice.

It seem to ignore shrinkwrapped packages as well: https://medium.com/@boennemann/avoid-yarn-for-packages-and-f...