It's a great read and feels good to know FB is solving problems that we all run into!
Yarn – A new package manager for JavaScript
311–320 of 486 posts
Re: Yarn – A new package manager for JavaScript
#312Yet Another... What does the R and the N stand for?
Re: Yarn – A new package manager for JavaScript
#313Earlier quoted context omitted.
What's the solution for that case though (one which requires no nesting)? I don't think a solution with no nesting exists given the current module resolution algorithm of Node.js, which allows for only a single version of a particular package to exist at a given level.
nesting can't be prevented in that case (at least with the current node require() design). It gets really bad if you have 10 packages that depend on c@1.0.0 and 10 packages that depend on c@2.0.0 -- one of them will install in the root directory and the other 10 will be duplicated. ied stores a single copy of each package@version and uses symlinks which is an improvement. Apparently yarn tried something similar but i…
I could be prevented. Another project does this by using a hash of the project to all all dependencies at one level then symlinks the dependencies from hash to name so it references the correct version.
Re: Yarn – A new package manager for JavaScript
#314Earlier quoted context omitted.
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?
In a local nexus/nuget repository in the intranet, for sure I'm not allowing internet access directly from a CI server.
And apart from the obvious and scary security concerns it is also much faster.
Re: Yarn – A new package manager for JavaScript
#315Earlier 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…
> Reading the article it seems to me that this micro packages approach is what slows down everything.
It really isn't. The NPM client is just really, really poorly written, with no parallelization to speak of.
Re: Yarn – A new package manager for JavaScript
#316Earlier quoted context omitted.
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.
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 solves it well. It behaves as any other tool would.
Re: Yarn – A new package manager for JavaScript
#317Earlier quoted context omitted.
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…
The problem does happen in JavaScript. But since its unityped, there is a strategy to deal with it * Figure out early on (before 1.0) what your base interface will be. For example, for a promise library, that would be `then` as specified by Promises/A+ * Check if the argument is an instance of the exact same version. This works well enough if you use `instanceof`, since classes defined in a different copy of the modu…
Would this even work in what I describe? For instance, if mat.normalize() was added in LA-6, and B provides an LA-5 mat, and then A (which has been updated to use the new method) calls mat.normalize() on the LA-5 mat expecting an LA-6 mat but because of duck-typing that method doesn't exist.
Re: Yarn – A new package manager for JavaScript
#318Earlier quoted context omitted.
I'm arguing for choosing dependency versions that don't require you to break the highlander rule. "a is updated to 2.0" doesn't mean you should start using that version of a right now.
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 distinguish a and b's versions of x. https://www.typescriptlang.org/docs/handbook/declaration-fil...
Re: Yarn – A new package manager for JavaScript
#319Earlier quoted context omitted.
Does anyone know why npm moves so slowly?
they have millions of installs and can't break them?
Do they necessarily have to break them to move faster? It's a package installer. Yarn is handling locking / shrinkwrapping different but I would argue shrinkwrap needs to be abandoned and re-done anyway so I'm not seeing the risk. It took them, what, two years just to flatten dependencies and move to npm 3? That was actively breaking Windows usage of node!
I love the service they offer. Not a fan of the tools or pace. Npm comes in the node installer so why do they even have to care about improving?
Just my thoughts.
Re: Yarn – A new package manager for JavaScript
#320Earlier quoted context omitted.
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?
In a local nexus/nuget repository in the intra net, for sure I'm not allowing internet access directly from a CI server. And apart from the obvious and scary security concerns it is also much faster.
Got it. You can also set up an NPM repository like that, but I don't think that that is commonly done by small dev teams. This does lead to hilarity like the left-pad clusterfork.