Yarn – A new package manager for JavaScript • Hacker News Board

Re: Yarn – A new package manager for JavaScript

#421

Post by yemsalat » Wed, Oct 12, 2016, 8:03 AM UTC

yemsalat wrote: post #416

jlongster wrote: post #191

Earlier quoted context omitted.

That big shift will have to happen first. I don't see them ever making their own registry unless 99.99% of people are using yarn and are having a lot of problems with the current npm registry. While I see a lot of people using yarn, I'm not sure about 99.99% and I think npm's registry itself is pretty good. So I don't think interests will ever align to create a new registry. Nobody wants to do that. That would have s…

Even if they don't get 99% of users (or any major percentage) I think it would still benefit the community to have an alternative to npm. Also Facebook has the advantage of not needing to make a business out of it (they already got a pretty good one) so in theory it could be entirely open source and free.

Just to expand on the stricter versioning rules that I mentioned, some things that in my opinion could improve the reliability of a package repository:

- strictly defined version update time intervals, e.g. you can't update your package more than once a week (or have to take some special actions for critical updates, e.g. contact support)

- "delayed" publishing, e.g. when you submit your package it will only be published in 24 hours, until then you can re-submit updates, etc.

- similar to above, but your package wont be published until it was tagged on github (or elsewhere) for a certain amount of time

- published packages can not be removed, but you can disassociate them with your account by marking them as "not maintained" and possibly assign new maintainers for it

- maybe introduce some way for developers to mark new versions as "backwards incompatible" if they do break backwards compatibility

I think there is definitely a "market" for some stricter node package repo.

Re: Yarn – A new package manager for JavaScript

#422

Post by imtringued » Wed, Oct 12, 2016, 8:19 AM UTC

prodigal_erik wrote: post #318

gakada wrote: post #300

Earlier quoted context omitted.

Right but what I'm saying is that two versions of the same library will live quite happily together, because node.js absolutely abhors global scope. The two versions have their own module-level scope to store functions and data. So go crazy and install every version of lodash! Nothing will break.

It's almost certain that a's version of x and b's version of x have distinct types whose names collide, and I don't know of any Typescript or Flow notation to prevent passing incompatible instances between them (e.g., a wants to call a method that didn't exist in b's version of x), so if anything works it's only by luck. Edit: I haven't dug into this, but it might be possible to use Typescript namespaces to distingui…

It's not possible to import two different versions of a module in the same module.

If a depends on x v1 and exports this dependency then your application also imports x v1. If b depends on x v2 and exports this dependency too that means your application is transitively importing both x v1 and x v2 which is not possible.

If a or b only use instances of x internally and do not accept instances of x as parameter or return an instance of x they don't have to export their dependency on x.

If either a or b do not export their dependency on x then there is no problem. Your application will only depend only on x v1 or x v2 directly.

Re: Yarn – A new package manager for JavaScript

#423

Post by tigershark » Wed, Oct 12, 2016, 8:27 AM UTC

rickhanlonii wrote: post #382

tigershark wrote: post #325

Earlier quoted context omitted.

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?

The benefit of what's happening in JS is that a lot of libraries are reasonably compartmentalized for a specific purpose. As an example: you _could_ have one SpockJS framework that gives you React + Redux + ReactRedux, but instead each of these libraries are separate so you can use them without each other. This allows you to, say, move from React to Angular without changing the state of your application. With everyth…

For testing it doesn't make any sense. I want a coherent and expressive framework that does everything. If I'm doing BDD I know that I will need everything from the start. And from the little that I have seen about jest..well it seems really a jest. I can't really think to do any serious BDD with that.

Re: Yarn – A new package manager for JavaScript

#424

Post by imtringued » Wed, Oct 12, 2016, 8:34 AM UTC

fryguy wrote: post #282

_greim_ wrote: post #174

Earlier quoted context omitted.

> Multiple versions [...] almost always a bad idea If so, different major versions of the same dep should be considered different libraries, for the sake of flattening. Consider lodash for example.

That can cause some serious problems in at least some portion of times. I've dealt with the subtle errors that have been caused by this problem in c++, and don't really know javascript libraries that well so I can't give a more concrete example. But imagine that there are the following libraries: * LA: handles linear algebra and defines a matrix object. * A: reads in a csv file and generates a matrix object using LA…

Define the matrix class in a seperate library for compatibility purposes if it's so widely used and doesn't change. Maybe some people don't need both the linear algebra and instead only the definition of the matrix object?

Another solution is to provide version overrides and make B depend on version 6.

However if there are differences in the matrix class between different versions of the library then you're forced to write a compatibility layer in any case.

Re: Yarn – A new package manager for JavaScript

#425

Post by StreamBright » Wed, Oct 12, 2016, 8:35 AM UTC

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…

You should check out the mayhem caused by a single contributor removing his left-pad library.

http://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/

Re: Yarn – A new package manager for JavaScript

#426

Post by imtringued » Wed, Oct 12, 2016, 8:45 AM UTC

rickhanlonii wrote: post #382

tigershark wrote: post #325

Earlier quoted context omitted.

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?

The benefit of what's happening in JS is that a lot of libraries are reasonably compartmentalized for a specific purpose. As an example: you _could_ have one SpockJS framework that gives you React + Redux + ReactRedux, but instead each of these libraries are separate so you can use them without each other. This allows you to, say, move from React to Angular without changing the state of your application. With everyth…

I guess you could call it "diversification" of dependencies. If one dependency stops being maintained or is not the best approach you can jump to another one.

Re: Yarn – A new package manager for JavaScript

#427

Post by romanovcode » Wed, Oct 12, 2016, 9:20 AM UTC

Doesn't work for me. My gulp builds are failing because they are missing some dependencies.

I'll continue using npm thank you very much.

Re: Yarn – A new package manager for JavaScript

#428

Post by imtringued » Wed, Oct 12, 2016, 9:24 AM UTC

smrtinsert wrote: post #212

andrewprock wrote: post #127

Earlier quoted context omitted.

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.

the haskell eliminator

Re: Yarn – A new package manager for JavaScript

#429

Post by ephimetheus » Wed, Oct 12, 2016, 10:37 AM UTC

Hm I like the idea, but in my testing, yarn is about 2 times slower than regular npm3...

EDIT: Even when it's hitting the cache, it's only ~5% faster than clean NPM with networking for me...

Re: Yarn – A new package manager for JavaScript

#430

Post by z3t4 » Wed, Oct 12, 2016, 10:43 AM UTC

I think it's naive to not review dependency updates. Also if a minor or patch update touches tens of thousands of files, you are dealing with a monster. And monsters need to be in cages.