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

211–220 of 486 posts

Re: Yarn – A new package manager for JavaScript

#211

Post by mambodog »

bcherny wrote: post #200
mambodog wrote: post #195

Earlier quoted context omitted.

> Flow, introduced 3 months after TypeScript Do you think Flow was built in 3 months as a reaction to Typescript? Not that it was a big enough problem that two different groups of people independently decided to try to solve it? EDIT: disregard this, Flow was introduced much longer than 3 months after TypeScript. The blog post introducing Flow mentions TypeScript, and is probably worth reading for background [1] > Nu…

> Do you think Flow was built in 3 months as a reaction to Typescript? They probably knew that TS was in progress when they started, but I don't have a window into that. I did ask some Flow devs a few weeks ago if they are interested in merging with TS, and they answered with a categorical no.

I can't speak for either project, but personally I would say that I don't think static typing in JS is a solved problem, and at this stage to me it seems a monoculture would be much less fruitful than a competition of ideas.

Re: Yarn – A new package manager for JavaScript

#212

Post by smrtinsert »

andrewprock wrote: post #127
__david__ wrote: post #122

Earlier quoted context omitted.

I'm sure that will fix itself very soon.

I'm sure it will. Search "go" on google, and the first link is the programming language. Search on any other search engine, and as one might expect, the definition or the game of go is ahead of the language.

Wait till I release my new programming language, 'the'. It's the go killer.

Re: Yarn – A new package manager for JavaScript

#214

Post by softawre »

sotojuan wrote: post #175
BinaryIdiot wrote: post #167

Earlier quoted context omitted.

I'm glad they're okay with it but then again what else would they post? npm has some major, major issues with it and it has barely moved in years . This Yarn looks like it solves quite a few issues with npm and it took another company to build it. That's insane. It wouldn't surprise me if yarn becomes popular and its proxy to npm slowly turns off and boom, everyone would be migrated and npm would be left with little…

Does anyone know why npm moves so slowly?

they have millions of installs and can't break them?

Re: Yarn – A new package manager for JavaScript

#215

Post by theanswerer »

ef4 wrote: post #32
jbverschoor wrote: post #10

"Linking: Finally, Yarn links everything together by copying all the files needed from the global cache into the local node_modules directory." Stop copying stuff. Just make it global and link. Next step is to make packages immutable and signed. I'm happy with this step and the fact that facebook will be able to push this.

Yeah, that would be much better. But unfortunately the node_modules structure (which yarn is attempting to be fully compatible with) makes that impossible. The reason is that each package only finds its dependencies relative to its own location. So your second level dependencies cannot vary from project to project unless you do copying. (Example: AppA and AppB depend on LibX. LibX depends on LibY. Through their deter…

You can make it work with `node --preserve-symlinks`

Re: Yarn – A new package manager for JavaScript

#216

Post by steveklabnik »

joepie91_ wrote: post #197
steveklabnik wrote: post #147

Earlier quoted context omitted.

How is this throwing away semver?

As I understand it, it automatically locks in the (exact) version of everything you install, rather than having this as a separate, optional feature (like shrinkwrap does, despite it not working well - but that's an implementation problem). The big deal about semver and how it's implemented in NPM is that there is a choice of how to deal with it - either you automatically allow compatible updates and risk an occasion…

  > Why bother with semantic versioning if everybody is expected to manually
  > check and pin their dependencies anyway?
I think this is the disconnect here: the lockfile does protect me from updates, but ranges are still useful: they allow a tool to help me upgrade my dependencies. With the lockfile-based approach, you usually _don't_ pin to specific versions: with Cargo, we even defaulted to the ^ operator, so 'foo = "1.2.3"' is the same as 'foo = "^1.2.3"'. So this is what happens:

  1. foo v1.2.3 comes out and I put that in my Cargo.toml.
  2. foo v1.3.0 comes out. My build doesn't change.
  3. I decide "hey, there's some new versions of my dependencies, let's upgrade."
  4. I type "cargo update". Now, my lockfile is updated to have 1.3.0 instead.
That is, ranges allow you to use semver as a tool. The big issue here is transitive dependencies; yes, for my own deps, I could have specified an exact version and done it every time. But what about the dependencies of my dependencies? Or the dependencies of the dependencies of my dependencies?

I totally understand your concerns about cargo-culting tooling, and that Facebook-sized organizations have different needs than non-Facebook sized ones. But repeatable builds are a big deal, and managing dependency ranges so you can still use semver while getting repeatable builds is a big deal. Even for smaller organizations.

(And that's beyond the speed and security aspects of yarn.)

Re: Yarn – A new package manager for JavaScript

#217

Post by qudat »

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…

Others have touched on the subject but one of the biggest issues is browser compatibility. Building a responsive website that works on all major browsers, across multiple versions, as well as all the mobile quirks is not an easy task in the slightest ... and that's just to make a site look pretty. Then we have to start talking about building massive web apps that are front-end heavy which requires even more tooling to scale, maintain properly.

Re: Yarn – A new package manager for JavaScript

#218

Post by bcherny »

mambodog wrote: post #211
bcherny wrote: post #200

Earlier quoted context omitted.

> Do you think Flow was built in 3 months as a reaction to Typescript? They probably knew that TS was in progress when they started, but I don't have a window into that. I did ask some Flow devs a few weeks ago if they are interested in merging with TS, and they answered with a categorical no.

I can't speak for either project, but personally I would say that I don't think static typing in JS is a solved problem, and at this stage to me it seems a monoculture would be much less fruitful than a competition of ideas.

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.

Re: Yarn – A new package manager for JavaScript

#219

Post by hbhakhra »

smrtinsert wrote: post #188
wycats wrote: post #88

Earlier quoted context omitted.

As a practical matter, the npm ecosystem today relies on duplication, and no new client that made the "highlander rule" (there can be only one) mandatory could succeed. Yarn does offer a `--flat` option that enforces the highlander rule, and I'm hopeful that the existence of this option will nudge the ecosystem towards an appreciation for fewer semver-major bumps and more ecosystem-wide effort to enable whole apps to…

Explain why duplication is mandatory?

Just imagine two packages you depend on (a and b) that both have a shared dependency (x). Both start off depending on x version 1.0 but then later a is updated to 2.0 while b isn't. Now you have two packages depending on different versions of the same package and hence the need for duplication. You have a that needs x@2.0 and b that needs x@1.0, so both copies are kept.

Re: Yarn – A new package manager for JavaScript

#220

Post by steveklabnik »

nodesocket wrote: post #213

Does yarn support custom `run` commands like npm? For example: "scripts": { "dev": "node api.js --config config-dev.json" } $ npm run dev

Yes. See the diff here for an example of moving a project from one to another: https://github.com/rust-lang/crates.io/pull/457

lots of "npm run" -> "yarn run" there.

Post reply on HN