
Everything You Wanted to Know About Yarn Package Manager - fizerkhan
https://www.atatus.com/blog/everything-you-wanted-to-know-about-yarn-package-manager/
======
eric_b
This post contains content that is plagiarized verbatim from other sources.
Namely Yehuda's blog post and the Yarn homepage itself.

~~~
noir_lord
[http://yehudakatz.com/2016/10/11/im-excited-to-work-on-
yarn-...](http://yehudakatz.com/2016/10/11/im-excited-to-work-on-yarn-the-new-
js-package-manager-2/) for those who where curious.

------
gotofritz
\- promises "everything you wanted to know about yarn"

\- has barely any content

~~~
sotojuan
What do you expect when Yarn has been out for less than a couple of weeks and
this person isn't involved with the project in any way?

~~~
wnevets
to not write an article proclaiming its everything?

~~~
sotojuan
Such is the problem with the majority of programming blog posts.

------
matthewmacleod
I have such a burning, unquenchable hatred for NPM that I just switched to
using Yarn. It's fine, has done what I expect it to, and hasn't caused any
problems so far. Maybe not an ideal solution, but for someone coming primarily
from languages that have non-shitty package managers it's a breath of fresh
air.

------
ittan
Yarn needs to learn from lein for clojure. Yarn is the wrong way forward, but
an incremental fix for npm.

~~~
ngrilly
What can be learnt from lein? (I've not used Clojure enough to know.)

------
Kiro
What's the benefit of having a lockfile compared to just specifying exact
versions in your package.json?

~~~
throwanem
Because you can only specify exact versions for your top-level dependencies.
Whether or not they pin versions of their own dependencies is up to their own
maintainers; you can't control it from package.json. And, while a lot of npm
packages adhere to semver and avoid shipping breaking changes on minor version
number bumps, a lot of npm packages _don 't_. So you can get hosed through no
fault of your own by an Nth-level dependency.

'npm shrinkwrap' solves this by pinning the currently installed versions of
everything under node_modules/, regardless of dependency depth. Yarn does the
same thing, but by default rather than, as with npm, an optional extra.
There's an argument to be made that the correct place to shrinkwrap, if you
want to, is in your build process. But I suspect that, in practice, Yarn
defaulting to it will prove a net positive, albeit a bit of a speedbump for
people looking to do turnkey migrations from npm.

~~~
Kiro
Oh, of course. Thank you!

------
kyriakos
anyone knows if yarn has an equivalent of --no-bin-links option?

EDIT: guess not according to
[https://github.com/yarnpkg/yarn/issues/929](https://github.com/yarnpkg/yarn/issues/929)

------
agnivade
Why can't all of this be patched in npm ? Why do we have to create a new tool
every time ?

It makes no sense and honestly makes me want to tear my hairs.

~~~
sotojuan
I don't get why people say this. You're acting like the npm team is desperate
for contributions and fixes and the Yarn people are like "No! We'll make our
OWN tool!".

It's the literal opposite. npm hasn't been open to contributions or fixes for
years.

~~~
throwanem
Really?
[https://github.com/npm/npm/pulls?q=is%3Apr+is%3Aclosed](https://github.com/npm/npm/pulls?q=is%3Apr+is%3Aclosed)
would seem to suggest otherwise. Should I be looking elsewhere? Is there
something I'm not seeing here?

~~~
doublerebel
I've contributed multiple issues and PRs which have been completely ignored.
It seems from the outside that their focus on monetizing causes their API to
be purposefully opaque and subject to change. It's been disappointing and
certainly turns me off from ever purchasing private repo hosting from npm
itself.

For reference:

[https://github.com/npm/npm/issues/12085](https://github.com/npm/npm/issues/12085)

[https://github.com/npm/npm/issues/8319](https://github.com/npm/npm/issues/8319)

[https://github.com/npm/couch-login/pull/13](https://github.com/npm/couch-
login/pull/13)

I have a deep understanding of how it works now, and therefore more to
contribute, but what's the point? I just keep running my own npm(s) instead
and contribute to packages that appreciate it.

~~~
throwanem
A strong statement, to be sure, for which one would hope to see equally strong
evidence. But two out of those three issues have unfulfilled requests for
followup. I'm not sure quite what you mean them to show.

