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

Yarn – A new package manager for JavaScript

code.facebook.com

Post reply on HN
Print view View original

301–310 of 486 posts

Re: Yarn – A new package manager for JavaScript

#301

Post by qudat »

stincity wrote: post #296
gkoberger wrote: post #294

Earlier quoted context omitted.

Is requiring Node really that bad? I don't write Bash or Ruby or Python or Go, but I have them all installed because various tools need them.

It doesn't make sense to require a backend tool for frontend technologies. That's just me though. So that's why I'm asking. Couldn't they just create a package system that's not based on some backend tech?

We have that and it's called `bower`. We moved away from it because having two package managers to manage javascript (one for front-end and one for back-end) is more insane than the issue you described.

Re: Yarn – A new package manager for JavaScript

#302

Post by steveklabnik »

stincity wrote: post #296
gkoberger wrote: post #294

Earlier quoted context omitted.

Is requiring Node really that bad? I don't write Bash or Ruby or Python or Go, but I have them all installed because various tools need them.

It doesn't make sense to require a backend tool for frontend technologies. That's just me though. So that's why I'm asking. Couldn't they just create a package system that's not based on some backend tech?

If you're writing a tool that's written in Javascript, you need an implementation of Javascript to make it work. Node, while focused on being "Javascript on the server", is also a really convenient way to get going with a Javascript runtime.

So yeah, in theory, you could create a whole 'nother binding to a runtime just for front-end tooling. Nobody's found node lacking enough to do that.

Re: Yarn – A new package manager for JavaScript

#303

Post by wtetzner »

thoughtpalette wrote: post #109
tranvu wrote: post #52

Earlier quoted context omitted.

Yarn isn't a replacement for npm itself. It's a client that can read/write to npm, and other registries such as Bower.

Well, it seems like it could be according to the article. What would you still need to use NPM (the cli) for, other than package hosting? According to http://blog.npmjs.org/post/151660845210/hello-yarn , it seems it doesn't work with private packages yet, which may or may not be an issue for your project. But it seems this is a complete CLI replacement for NPM.

Yes, it replaces the client, but it uses the same package repository and package format.

Re: Yarn – A new package manager for JavaScript

#304

Post by striking »

ssunstruck wrote: post #255
striking wrote: post #225

Earlier quoted context omitted.

Well, but remember that time they shipped an SSL cert that broke all updated clients? I'm not sure they move slowly because they don't want to break things, because that would have been a pretty easy bug to catch... http://blog.npmjs.org/post/78165272245/more-help-with-selfsi...

That's not really a good counter example. It's more of a mistake on a release...

It's more of a failure to double check that npm runs when you change the SSL cert you bundled with it.

I think it's a great example of moving a little too quickly, honestly. Especially since it bricked plenty of npm installs instead of being "just another bug".

Re: Yarn – A new package manager for JavaScript

#305

Post by happyslobro »

tigershark wrote: post #288
erikpukinskis wrote: post #250

Earlier quoted context omitted.

What do you find maddening about micro packages? I hate depending on a giant stack of frameworks (slowing installs, builds, adding behavior surface area) when I just need a function or two, so micro packages are a joy for me.

Reading the article it seems to me that this micro packages approach is what slows down everything. I never, ever have seen all these problems in even not-so-state-of-the-art dependency managers like maven or nuget. Seriously up to now it was impossible to have a build server isolated from the internet if you didn't want to check-in all the dependencies??? Simply crazy. I really can't understand how people can even t…

Where would a CI server retrieve dependencies from, if not either over the network, or from within the repository? Do you keep a module / library cache on the CI server itself? In other words, what do supply as input to your CI process, besides a Git URL?

Re: Yarn – A new package manager for JavaScript

#306

Post by [deleted] »

BinaryIdiot wrote: post #187

I'm really liking yarn. It solves some of my main issues with npm, it's fast and it provides some great output in the CLI. It's also architected absolutely ingeniously . Seriously they have positioned themselves to seamlessly take over npm's entire business just like that. What do I mean? So today by default yarn goes through its servers which then proxy to npm's. As time goes Facebook can add more features to its ow…

[deleted]

Re: Yarn – A new package manager for JavaScript

#308

Post by untog »

erikpukinskis wrote: post #250
grayrest wrote: post #207

Earlier quoted context omitted.

> Are people really making projects with dozens (hundreds? more?) of dependent libraries? Yes. > Are there aspects of the language or runtime that reward multiple layers of configuration management? A significant fraction of the node community likes to split their project into really, really small packages and treat them as if they're independent even if they come from the same source repo and tend to get used togeth…

What do you find maddening about micro packages? I hate depending on a giant stack of frameworks (slowing installs, builds, adding behavior surface area) when I just need a function or two, so micro packages are a joy for me.

But a huge list of micro packages slows installs, too. It shouldn't, but NPM doesn't seem very good at parallelising operations.

Re: Yarn – A new package manager for JavaScript

#309

Post by stincity »

qudat wrote: post #301
stincity wrote: post #296

Earlier quoted context omitted.

It doesn't make sense to require a backend tool for frontend technologies. That's just me though. So that's why I'm asking. Couldn't they just create a package system that's not based on some backend tech?

We have that and it's called `bower`. We moved away from it because having two package managers to manage javascript (one for front-end and one for back-end) is more insane than the issue you described.

Love that. Let's include a backend tool for just so our frontend stuff can work. Makes sense.
Post reply on HN