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

321–330 of 486 posts

Re: Yarn – A new package manager for JavaScript

#321

Post by electic »

Doesn't seem to be very bug free atm:

yarn yarn install v0.15.1 info No lockfile found. [1/4] Resolving packages... error https://registry.yarnpkg.com/babel-code-frame: socket hang up at createHangUpError (_http_client.js:252:15) at TLSSocket.socketCloseListener (_http_client.js:284:23) at emitOne (events.js:101:20) at TLSSocket.emit (events.js:188:7) at TCP._handle.close [as _onclose] (net.js:493:12) info Visit http://yarnpkg.com/en/docs/cli/install for documentation about this command.

Re: Yarn – A new package manager for JavaScript

#322

Post by odbol_ »

wycats wrote: post #241
odbol_ wrote: post #182

Earlier quoted context omitted.

Compared to C/C++ tooling and package managers, npm is like taking a bazooka to a knife fight.

Is npm the bazooka or C++? As someone who's worked with C/C++ (and its hilarious explosion of tooling -- half-a-dozen at Google alone), maven, bundler and Cargo, I think it's just not accurate to say that the npm ecosystem has a particularly high level of complexity.

npm is the bazooka. Covers a lot more area with a single tool, but sometimes dangerous if you use it wrong.

C/C++ tooling is a plastic butterknife you get with airplane food.

Re: Yarn – A new package manager for JavaScript

#323

Post by aphextron »

bandrami wrote: post #131

This may come off as a troll, but it's an honest question. I'm not a javascript guy. It's not a language I deal with at all. Why on God's green earth does it need as much tooling as it seems to have? Are people really making projects with dozens (hundreds? more?) of dependent libraries? Are there aspects of the language or runtime that reward multiple layers of configuration management? In short, what the hell is up…

>Are people really making projects with dozens (hundreds? more?) of dependent libraries?

Yes, because the standard library provides practically nothing useful in itself.

Re: Yarn – A new package manager for JavaScript

#324

Post by odbol_ »

pfooti wrote: post #118

There's a lot to like here - deterministic builds are great. However, yarn doesn't currently seem to support installing straight from github or private packages [0], [1]. I'm sure this will be added in the future, but it is currently a dealbreaker for me - I'm using a single package that's just straight hosted in a private git repo, as the package itself isn't ready to be published yet. I'm sure other people are usin…

Yeah, this is like the main reason I love npm: ability to use a Github repo as a package repo.

Re: Yarn – A new package manager for JavaScript

#325

Post by tigershark »

pcsanwald wrote: post #181
bandrami wrote: post #131

This may come off as a troll, but it's an honest question. I'm not a javascript guy. It's not a language I deal with at all. Why on God's green earth does it need as much tooling as it seems to have? Are people really making projects with dozens (hundreds? more?) of dependent libraries? Are there aspects of the language or runtime that reward multiple layers of configuration management? In short, what the hell is up…

I have no idea if you're familiar with the java ecosystem, but I am, so I'll use that as an example: Node libraries are typically several orders of magnitude smaller and more single purpose than java libraries. Java libraries like Guava and Spring are typically quite large. A practical example is from unit testing: In Java, you might use JUnit+Mockito for your test dependencies. In Node, to get similar functionality,…

Why is that? In the Java ecosystem there is Spock framework that gives you everything required for testing, you don't even need junit+mockito. In which scenario would be better to use 11 different libraries for doing the same thing as a well written framework?

Re: Yarn – A new package manager for JavaScript

#326

Post by [deleted] »

iamleppert wrote: post #203

This is not a problem with the package manager. This is a problem with complexity. When did it start becoming reasonable for a front-end only part of the MVCC pattern to have 68 dependencies? Or for a transpiler like Babel to add 100k+ files? I'm sorry I just find it ridiculous that instead of taking a look at the disease (unbounded complexity), we are looking to engineer our way out of the problem by creating a pack…

[deleted]

Re: Yarn – A new package manager for JavaScript

#327

Post by bcherny »

mlsarecmg wrote: post #316
bcherny wrote: post #218

Earlier quoted context omitted.

I would agree if they were at all different, but they seem to be syntactically and functionally identical. As a caveat, I am a daily TS user, and have only played around with Flow.

I think the issue is that TS is non-modular and dictates javascripts reach. It behaves like no other tool and blocks others from working. Take something like React/Redux for instance, which are built around modern day javascript, but if you transpile any example on the official Redux page right now you will see TS bail out because it can't understand some of the syntax. Flow on the other hand solves one problem and s…

Not sure I understand. Can you give a concrete example?

Re: Yarn – A new package manager for JavaScript

#330

Post by l1ambda »

tigershark wrote: post #325
pcsanwald wrote: post #181

Earlier quoted context omitted.

I have no idea if you're familiar with the java ecosystem, but I am, so I'll use that as an example: Node libraries are typically several orders of magnitude smaller and more single purpose than java libraries. Java libraries like Guava and Spring are typically quite large. A practical example is from unit testing: In Java, you might use JUnit+Mockito for your test dependencies. In Node, to get similar functionality,…

Why is that? In the Java ecosystem there is Spock framework that gives you everything required for testing, you don't even need junit+mockito. In which scenario would be better to use 11 different libraries for doing the same thing as a well written framework?

In this case, I would argue it is not better. Many JS devs have moved onto simpler, greener pastures. https://github.com/substack/tape is what I prefer. Small little library. Its API has everything I need and nothing I don't. Those other test libraries listed are pretty much overkill.

Similar with http://mithril.js.org/ over React, Angular and Ember. A single drop-in library with 13 functions in it's API. The library itself is a single, understandable source code file. Mithril is pretty much the exact opposite of Angular and Ember.

A lot of front end devs are eschewing frameworks completely. With modern DOM and web APIs, you can do a lot with "just" vanillajs.

Post reply on HN