Why another project? If npm has been suitable and only falls short in certain cases, why not contribute back to it?
Yarn – A new package manager for JavaScript
151–160 of 486 posts
Re: Yarn – A new package manager for JavaScript
#152The algorithm sounds very much like how Dart's "pub" command works. Anyone know how they differ?
Re: Yarn – A new package manager for JavaScript
#153This 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…
Basically I think it comes down to:
1. In the browser we have less control over the environment the code runs in, requiring tooling to achieve a stable, normalised environment which we can improve at our own pace, rather than the rate at which browsers are updated.
2. JS has become very widely used very quickly, which means that there have been lots of hastily built things, which have been replaced by better things (and for every 'better thing' there are many alternatives which fell by the wayside), and a larger pool of people to build them.
3. It's easier than ever to build new tools (or any kind of app, for that matter), because the npm ecosystem makes it trivial to combine existing smaller pieces of code into new combinations.
Re: Yarn – A new package manager for JavaScript
#154Earlier 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…
Mhm that sounds reasonable.
I haven't gotten into problems with versions yet but I don't really trust npm update, because I am not always sure how it behaves.
From a build tool perspective (we use npm scripts for basically everything [and some webpack]) I am also not missing something particular.
Looking at other comparable solutions (from other languages) I'd say npm does a pretty good job.
Re: Yarn – A new package manager for JavaScript
#155 console.log("u got powned")Re: Yarn – A new package manager for JavaScript
#156There'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…
This. I came here to say this also.
In ruby if you want to patch a repo for yourself you just fork it and make changes and then in bundler point to the git url (often on github). Then run bundle install and you're set.
With npm I've been frustrated a few times whereby you can fork the repo and point package.json to the git repo but after running npm I usually get a bunch of compilation errors.
It would be wonderful to make this as simple as with bundler within the ruby ecosystem, point to forked url and running yarn handles the rest.
Re: Yarn – A new package manager for JavaScript
#157Earlier quoted context omitted.
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…
The fun of kicking off a CI build after the weekend with no commits and see stuff randomly break because some dependency of a dependency got updated and broke things in a minor version is something I've only experienced in JS - beautiful.
Well, now you can do that in Cargo as well :-)
What we do currently is we lock everything to an explicit version - even libraries.
At least it's possible to get deterministic builds if you are willing to do a bit of work carefully / manually updating all of your dependencies at once.
Re: Yarn – A new package manager for JavaScript
#158"The React Native package.json currently lists just 68 dependencies, but after running npm install the node_modules directory contains 121,358 files." That, to me, is what is wrong with npm. The problem stems from node.js not coming with "batteries included" so there is a proliferation of tiny libraries that do the most trivial things.
> That, to me, is what is wrong with npm. The problem stems from node.js not coming with "batteries included" so there is a proliferation of tiny libraries that do the most trivial things.
This is in no way a fault of node.js but of the whole JS standard. People these days use npm modules to run in a browser and ship stuff bundled together with webpack (or other bundlers), so even if nodejs had a proper stdlib, you'd still need to depend on a polyfill so that your stuff works in a browser environment, too.
And due to the fact that even if a sane stdlib would ever be standardized, it would take YEARS of time until it reaches significant market share (looking at you, Android, Safari and IE), so you'd always have to ship a polyfill.
Re: Yarn – A new package manager for JavaScript
#159Why another project? If npm has been suitable and only falls short in certain cases, why not contribute back to it?
It's unlikely npm would accept patches moving it in the direction Yarn is taking. Different priorities.
Re: Yarn – A new package manager for JavaScript
#160Here is npm's response: http://blog.npmjs.org/post/151660845210/hello-yarn
Looks like they are trying to write off yarn as just another alternative install tool. I think this is short cited and hope they are taking this threat more seriously internally.