Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Yarn 1.0: Workspaces, auto-merging lockfiles, selective versions resolutions

code.facebook.com

Post reply on HN
Print view View original

41–48 of 48 posts

Re: Yarn 1.0: Workspaces, auto-merging lockfiles, selective versions resolutions

#41

Post by spraak »

brad0 wrote: post #18
petetnt wrote: post #16

Earlier quoted context omitted.

> If yarn had been approached with more senior developers I think it could have replaced npm entirely. The biggest reason by far why Yarn got so popular so quickly was because it didn't come and try to split the existing ecosystem but chose build on top of npm's foundation with ways that npm didn't (at that point) offer instead.

Yes I agree! I didn't really make myself clear. I feel that if yarn kept its strategy but had more senior developers writing the core software I think it could have been able to outpace npm in terms of features and speed. If this had have been the case then it wouldn't make sense to use npm at all. Yarn would be faster and have more features. From my experience I feel that yarn isn't offering much value now and the c…

The appeal to most that I've seen, myself included, is that yarn is faster than npm. Is that not your experience?

Re: Yarn 1.0: Workspaces, auto-merging lockfiles, selective versions resolutions

#42

Post by tarr11 »

BYK wrote: post #5
BYK wrote: post #4

Earlier quoted context omitted.

We have patched that issue and already tagged 1.0.1 ;)

See https://github.com/yarnpkg/yarn/issues/4320

Looks like its still having problems on Heroku

https://github.com/heroku/heroku-buildpack-nodejs/issues/468

Re: Yarn 1.0: Workspaces, auto-merging lockfiles, selective versions resolutions

#43

Post by scarlac »

msoad wrote: post #17

Maybe Node should bundle Yarn instead of NPM? NPM is so buggy I can't stand it for a minute!

Not quite the same but ironically the standard "node" Docker image contains yarn: https://github.com/nodejs/docker-node/blob/b502aa016335c81a5...

Re: Yarn 1.0: Workspaces, auto-merging lockfiles, selective versions resolutions

#44

Post by onestone »

scarlac wrote: post #43
msoad wrote: post #17

Maybe Node should bundle Yarn instead of NPM? NPM is so buggy I can't stand it for a minute!

Not quite the same but ironically the standard "node" Docker image contains yarn: https://github.com/nodejs/docker-node/blob/b502aa016335c81a5...

I was the one who added Yarn to the official docker-node image[1][2]. This was the most popular docker-node feature request at the time. We managed to achieve it with a minimal size increase (with the help of the awesome Yarn team) and without affecting anything else. There was already a history of us providing some bonus features which the upstream Node project doesn't, such as a musl-libc build (for Alpine Linux).

[1] https://github.com/nodejs/docker-node/pull/337 [2] https://github.com/nodejs/docker-node/pull/403

Re: Yarn 1.0: Workspaces, auto-merging lockfiles, selective versions resolutions

#45

Post by MikeTaylor »

Just in case anyone else runs into this and doesn't know what's going on: we had a problem with Yarn 1.0, because it doesn't recognise repositories that don't end in a trailing slash -- for example, "@folio:registry=https://repository.folio.org/repository/npm-folio" is no good any more, but "@folio:registry=https://repository.folio.org/repository/npm-folio/" is. See https://github.com/folio-org/stripes-demo-platform/commit/f8...

Meanwhile ... I do regret that this doesn't introduce alternative dependencies, like Debian packages have, where your package foo can have dependency on "either bar or baz". Oh well.

Re: Yarn 1.0: Workspaces, auto-merging lockfiles, selective versions resolutions

#46

Post by Lazare »

marricks wrote: post #19

What was the compelling reason to make Yarn instead of contributing to npm, perhaps ownership? Seems like they could given everyone a lot of improvements and instead they fractured the market a bit.

Although there have been marked improvements recently, the npm project has been crippled by politics. Much of what yarn fixed were issues that technically could have been easily fixed in npm, but could not be due to political concerns.

For example, the npm project was reluctant to make any changes that broke backwards compatibility, even when the existing feature was outright unusable (eg, shrinkwrap). By contrast, Yarn was free to break backwards compatibility since it was a new project, and it's popularity, in turn, allowed npm to finally feel free to start fixing things.

Yarn has helped npm hugely in my view, but it was only able to do so as an independent project. The current version of npm has working lockfiles because Yarn shipped working lockfiles, but every proposal to fix them pre-yarn was shot down out of hand for (in my view) nonsense reasons.

(This helps explain, incidentally, why yarn has had some much support from parts of the npm dev team. They knew, eg, lockfiles had to be fixed, and if it took yarn as a catalyst, so be it.)

Re: Yarn 1.0: Workspaces, auto-merging lockfiles, selective versions resolutions

#47

Post by BYK »

MikeTaylor wrote: post #45

Just in case anyone else runs into this and doesn't know what's going on: we had a problem with Yarn 1.0, because it doesn't recognise repositories that don't end in a trailing slash -- for example, "@folio:registry= https://repository.folio.org/repository/npm-folio" is no good any more, but "@folio:registry= https://repository.folio.org/repository/npm-folio/" is. See https://github.com/folio-org/stripes-demo-platfor…

Apologies for the issue. There's an issue file on GitHub for this and we are working on a fix: https://github.com/yarnpkg/yarn/issues/4339

Re: Yarn 1.0: Workspaces, auto-merging lockfiles, selective versions resolutions

#48

Post by [deleted] »

nailer wrote: post #37
allover wrote: post #29

Earlier quoted context omitted.

RE the 2nd issue: Are you sure you even need `private: true`? Scoped modules are private by default right? I thought `private: true` was supposed to prevent publishing to npm altogether. It's odd they haven't at least triaged the issue (but you know humans/time). That said the fact it's a niche workflow (it's unclear why the user is using --no-save) and the steps to reproduce won't be doable by the team ... probably…

The packages aren't published on npm but deployed by other means (before npm is used to install additional public packages), hence 'private' is deliberate.

[deleted]
Post reply on HN