5 ms·

I'm super excited to use yarn but, just a heads up, we hit this pretty severe issue when setting it up for our projects: https://github.com/yarnpkg/yarn/issues/

I'm super excited to use yarn but, just a heads up, we hit this pretty severe issue when setting it up for our projects: https://github.com/yarnpkg/yarn/issues/761 https://github.com/yarnpkg/yarn/issues/761

octref 10y ago
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 https://github.com/yarnpkg/yarn/releases/tag/v0.16.0
- amasad 10y ago
  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.
Etheryte 10y ago
Likewise, can't wait for yarn to finish its growing pains, until then it's still npm.
po1nter 10y ago
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 https://github.com/yarnpkg/yarn/issues/616
- ceejayoz 10y ago
  Out of curiosity, why use npm and bower in the same project?
  - joshstrange 10y ago
    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.
    - gotofritz 10y ago
      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.
      - Sacho 10y ago
        How would you migrate libraries that are only on bower, not npm?
        ceejayoz 10y ago
        How many of those are a) left and b) still maintained?
        gotofritz 10y ago
        If there are still any in 2016 it's a good sign they are not begin actively maintained
      - ferentchak 10y ago
        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?"
cel1ne 10y ago
It seem to ignore shrinkwrapped packages as well: https://medium.com/@boennemann/avoid-yarn-for-packages-and-fully-enjoy-its-benefits-for-application-development-8bdd4deb33cf#.q44b7arec https://medium.com/@boennemann/avoid-yarn-for-packages-and-f...
vonklaus 10y ago
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.

octref 10y ago

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 https://github.com/yarnpkg/yarn/releases/tag/v0.16.0

amasad 10y ago
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.

Etheryte 10y ago

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

po1nter 10y ago

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 https://github.com/yarnpkg/yarn/issues/616

ceejayoz 10y ago
Out of curiosity, why use npm and bower in the same project?
- joshstrange 10y ago
  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.
  - gotofritz 10y ago
    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.
    - Sacho 10y ago
      How would you migrate libraries that are only on bower, not npm?
      - ceejayoz 10y ago
        How many of those are a) left and b) still maintained?
      - gotofritz 10y ago
        If there are still any in 2016 it's a good sign they are not begin actively maintained
    - ferentchak 10y ago
      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?"

cel1ne 10y ago

It seem to ignore shrinkwrapped packages as well: https://medium.com/@boennemann/avoid-yarn-for-packages-and-fully-enjoy-its-benefits-for-application-development-8bdd4deb33cf#.q44b7arec https://medium.com/@boennemann/avoid-yarn-for-packages-and-f...

vonklaus 10y ago

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.