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

31–40 of 48 posts

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

#31

Post by Klathmon »

firloop wrote: post #20

Will Yarn ever be merged into npm's CLI? Why does the node community back two package managers?

The same reason most people back multiple browser rendering engines, or multiple car manufacturers, or multiple CPU manufacturers.

Competition is good, and having 2 implementations of the same basic idea that each prioritise different things means that more people can have their cake and eat it too.

Having one tool that has hundreds of flags to enable different use-cases is an anti-pattern in my opinion, and a fantastic alternative is to create multiple competing tools that each handle those different use-cases. It's the unix philosophy taken to the extreme, each "program" should do one thing, and do it well.

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

#32

Post by zuck9 »

brad0 wrote: post #7
orta wrote: post #2

A big congrats are in order. Yarn came out just as I started working in the node ecosystem, and it fixed nearly all my dependency manager problems. Since then it's evolved and it's really helped provide a counter to npm offering different design choices but working together where it counts. It's the 4th most popular brew dependency and ~25% of npm downloads. People love it. Congrats Yarn team - you've been doing a gr…

I jumped on node around the same time and I've come to an opposite conclusion. The things I liked was the offline cache and the yarn integrity. However there was just too many issues regarding its dependency on npm and not playing nice with other tools such as brew. I dove into the code to try and fix these issues but both the quality of the code base and the politics going on in the issue tracker turned me off very…

The issue you linked seems to be fixed in this release. Any other issues that's keeping you from adopting Yarn?

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

#33

Post by tarr11 »

adamgiacomelli wrote: post #3

I have had a failed heroku deployment because of yarn 1.0 yesterday - quite interesting. Made me define the yarn version in package.json. I have also had some problems with the yarn repo being unavailable a couple of months ago. That being said - I have migrated to it completely on all projects and never looked back - so yay for yarn!

My heroku deploy succeeded, but my CircleCI run failed for the same reason. Had to upgrade package.json as well, since my circleci build downloads yarn each time. Probably not the most efficient way of doing this but it worked...

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

#34

Post by slavik81 »

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…

Perhaps I'm wrong, but from your posts here I don't get the sense that you were close enough to the project to really know their team composition or how to improve it. Your prescription comes off as armchair quarterbacking.

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

#35

Post by Rapzid »

nwlieb wrote: post #12

This is fantastic! The biggest standout feature in my opinion is workspaces. I've been using workspaces on a client project with many sub-projects and it has been a pleasure. Shared modularized code without creating private npm packages or doing some "linking" magic has been wonderful for productivity. It's as simple as creating another local package and symatically everything else has remained the same as a regular…

How are people handling CI/CD servers/services with the mono repo?

The barrier to mono repo seems to have always been the need to create massive amounts of bespoke tooling to handle the build pipelines(how do I build just this proj?, how do I run tests on just this proj?, how do I build just this proj and its deps?, etc). These are totally solvable with dedicated dev resources, but these are typically the problems you try to avoid rather than spend time on at a lot of companies; say Workspaces and Lerna seem to be a small piece of the puzzle even if critical. Are there tools to help out with rest? For instance if I'm using Bitbucket pipelines, what should I be looking for to help building from a mono repo?

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

#37

Post by nailer »

allover wrote: post #29
nailer wrote: post #11

Earlier quoted context omitted.

There's a couple of similar deletion issues, they're all linked from https://github.com/npm/npm/issues/17929 , the deleting private one happens in all situations, eg just an npm install, see https://github.com/npm/npm/issues/17927

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.

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

#38

Post by hinkley »

Rapzid wrote: post #35
nwlieb wrote: post #12

This is fantastic! The biggest standout feature in my opinion is workspaces. I've been using workspaces on a client project with many sub-projects and it has been a pleasure. Shared modularized code without creating private npm packages or doing some "linking" magic has been wonderful for productivity. It's as simple as creating another local package and symatically everything else has remained the same as a regular…

How are people handling CI/CD servers/services with the mono repo? The barrier to mono repo seems to have always been the need to create massive amounts of bespoke tooling to handle the build pipelines(how do I build just this proj?, how do I run tests on just this proj?, how do I build just this proj and its deps?, etc). These are totally solvable with dedicated dev resources, but these are typically the problems yo…

Subversion used to let you check out a subdirectory of a repo, which generally helped with this problem. The chapter on SVN in Beautiful Code does a great job of explaining how this works and why it helps with concurrent access to the repo.

This is a giant blind spot in Git, and none of the proposed workarounds come anywhere close to the tiny cognitive load of svn's answer to this problem.

But nobody on the git design committee seems to give a shit about cognitive load, so I'm probably just shouting into the tempest.

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

#40

Post by firloop »

Klathmon wrote: post #31
firloop wrote: post #20

Will Yarn ever be merged into npm's CLI? Why does the node community back two package managers?

The same reason most people back multiple browser rendering engines, or multiple car manufacturers, or multiple CPU manufacturers. Competition is good, and having 2 implementations of the same basic idea that each prioritise different things means that more people can have their cake and eat it too. Having one tool that has hundreds of flags to enable different use-cases is an anti-pattern in my opinion, and a fantas…

This is a good answer that changed my perspective, thanks.
Post reply on HN