Anybody know what yarn does when it encounters a "*" version?
Yarn – A new package manager for JavaScript
411–420 of 486 posts
Re: Yarn – A new package manager for JavaScript
#412Re: Yarn – A new package manager for JavaScript
#413NPM must have been the only thing the JS community has standardised on. Now that's gone too
Re: Yarn – A new package manager for JavaScript
#414This 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…
Handling dependencies is hard. Handling dependencies for a platform you don't control is harder. Handling dependencies for a platform you don't control, where every single kilobytes count, is insane. Add those together, and you get the need for real complex tooling. With that said, tooling is nowhere as complex as it is for languages like C++ or Java. People are just used to it on those platforms, and the tooling is…
The tooling for building C++ consists of make or something that generates make files. There's also no "1 function" libraries.
Adding a dependency is done by (compiling it if needed) and referencing it from the make file.
It's super easy to understand, but involves manual work because C++ doesn't have a package manager.
Java isn't too complicated either. I've used Gradle and Maven but doing things manually like in C++ can also work.
Crucially, they don't reinvent the wheel every couple of months so a C++ or Java dev can focus on building things instead of relearning how to build things.
Re: Yarn – A new package manager for JavaScript
#415It's incredible that a tool that we've tolerated for years, npm, is instantly and unceremoniously dumped for a superior offering, yarn. Technology changes on a dime.
Re: Yarn – A new package manager for JavaScript
#416Earlier quoted context omitted.
> Yarn pulls packages from registry.yarnpkg.com, which allows them to run experiments with the Yarn client. This is a proxy that pulls packages from the official npm registry, much like npmjs.cf.[0] Time will tell whether they only want to be proxying NPM or will allow direct pushing to their own registry. If they do, JS ecosystem might see another big shift. [0] http://blog.npmjs.org/post/151660845210/hello-yarn
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.
Re: Yarn – A new package manager for JavaScript
#417I don't know JS and I've never used these js package managers, but are these issues such that they couldn't have been fixed in the original package manager? Smells like NIH that is just going to create head ache and misery for everyone in the JS community in the long term.
Re: Yarn – A new package manager for JavaScript
#418Earlier quoted context omitted.
How does it flatten dependencies? Symlinks?
no, it just installs everything it can into the top level node_modules. npm@2 would do this to a degree as well, it was just less sophisticated about it.
> into the top level node_modules.
Just tried using npm3 explicitly and I stand corrected.
Re: Yarn – A new package manager for JavaScript
#419Earlier quoted context omitted.
Would you mind going a bit into detail? I work with npm on a daily basis and I am pretty happy so far.
The whole version range stuff got me many times. I went to use fixed versions on my own package.json files, but the deps of my deps could still be dynamic, which is even worse, since they sit deeper in my dependency graph AND there are more indirect deps than direct deps. (~50 direct, >200 indirect) Also, npm isn't deterministic and it got even worse with v3. Sometimes you get a flat list of libs, if a lib is used wi…
NPM is deterministic when there using the same package.json and there is no existing node_modules folder.
And if you want to lock versions for your entire dependency tree, npm shrinkwrap is what you're looking for (It's essentially the same as lockfiles in other development package managers). Though for security reasons I prefer to keep things locked to a major version only (e.g. "^2.0.0"). Shrinkwrapping is useful in this instance too if you need to have predictable builds (and installs as it'll use the shrinkwrap when installing dependencies too if it's a library rather than the main app) but want to ensure your dependencies stay up to date.
It's not perfect by any measure, but there are ways to make it work the way you want.
Re: Yarn – A new package manager for JavaScript
#420Here is npm's response: http://blog.npmjs.org/post/151660845210/hello-yarn
It is quite a congenial response and no disrespect to npm inc, but yarn will be technically far superior (if it's not already), and I can't help but interpret this as the beginning of the end for npm....It was only a matter of time though since there are a number of systemic problems with npm and (in my opinion) it is at the center of the dysfunctional world of modern JavaScript tooling. It did move the ecosystem for…
NPM can evolve; Gradle and SBT also didn't turn out to be the end of Maven, which evolved to being more of a repository and dependency management tool with multiple clients.