31–40 of 57 posts
> npm's default git branch is no longer `master`. We'll be using `latest` from now on. Is there any reason to do this?
(Personally, I think `latest` conveys the intended meaning with more clarity, but I don't like the way Node/npm deals with language and community conduct)
After using yarn for a week, I can't imagine going back to npm. I use npm 90% for install, and yarn does this so much better. Installs are 3-4 times faster. Output is minimal and readable (compared to npm's wall of text that I never read). Packages are cached so I can work with slow connections in coffee shops. Sorry to be blunt, but I feel none of the release features gonna help my daily usage of npm. How about actu…
I don't mean to be rude, but your last paragraph comes across a bit strange, it sounds like you have a sense of entitlement to having NPM work the way you want. The project is open source, you can fix it, send a pull request, and the whole community will benefit. I wonder if it would have been better if the Yarn developers would had done the same.
After using yarn for a week, I can't imagine going back to npm. I use npm 90% for install, and yarn does this so much better. Installs are 3-4 times faster. Output is minimal and readable (compared to npm's wall of text that I never read). Packages are cached so I can work with slow connections in coffee shops. Sorry to be blunt, but I feel none of the release features gonna help my daily usage of npm. How about actu…
Except now there's another competing standard in the JavaScript world. How long until a feature is added to Yarn and not NPM or vice versa, and a package only works in one of them? I don't mean to be rude, but your last paragraph comes across a bit strange, it sounds like you have a sense of entitlement to having NPM work the way you want. The project is open source, you can fix it, send a pull request, and the whole…
1. We have a finite amount of time each week just like everyone else. Fixing a problem with an open source project might consume a couple weeks of free time just for a tiny bug fix, because of the time it takes to learn a new code base, get tests running, and other administrative details. Larger fixes might consume an entire year.
2. Sometimes, problems are design flaws and can't really be made into pull requests. I have a strong suspicion that some of the problems with NPM fall into this camp, based on my personal experiences with NPM and how badly it performs some of its basic tasks relative to the project's age and maturity.
I'm going to flip this around, so please forgive if this seems trite, but it sounds like you have a sense of entitlement yourself. Users do not "owe" the projects they use pull requests just because it's possible. Users have their own goals and motivations, and if a competing program is simply better than the program you like (from some users' perspective) it's absurd to blame the users for it.
(I mean, from personal experience NPM is an astoundingly poor package manager. I've had it OOM on me on VMs for the most basic of tasks, and some commands are completely unusable.)
After using yarn for a week, I can't imagine going back to npm. I use npm 90% for install, and yarn does this so much better. Installs are 3-4 times faster. Output is minimal and readable (compared to npm's wall of text that I never read). Packages are cached so I can work with slow connections in coffee shops. Sorry to be blunt, but I feel none of the release features gonna help my daily usage of npm. How about actu…
"The easiest way to get started is to run: npm install -g yarn"
After using yarn for a week, I can't imagine going back to npm. I use npm 90% for install, and yarn does this so much better. Installs are 3-4 times faster. Output is minimal and readable (compared to npm's wall of text that I never read). Packages are cached so I can work with slow connections in coffee shops. Sorry to be blunt, but I feel none of the release features gonna help my daily usage of npm. How about actu…
Except now there's another competing standard in the JavaScript world. How long until a feature is added to Yarn and not NPM or vice versa, and a package only works in one of them? I don't mean to be rude, but your last paragraph comes across a bit strange, it sounds like you have a sense of entitlement to having NPM work the way you want. The project is open source, you can fix it, send a pull request, and the whole…
However, experience has proven that it is difficult to actually contribute--even in active repo like npm. Every project has there own standards and unwritten rules. Further, many repo maintainers are unresponsive after initial contact, adding frustration to an already frustrating process of getting work put in.
Let's take npm/npm as an example. There is no easy to find contributing guidelines, thousands of open issues, and pull requests that have been open for months where the author requests more info so they can complete their work but without an answer. All of this leads to a contributor-hostile experience.
I think we as a community should consolidate the contribution process, and start treating that as a product and gets the same love the code does.
> npm's default git branch is no longer `master`. We'll be using `latest` from now on. Is there any reason to do this?
It's probably to prevent any association with slavery (i.e. "master" owns slaves ) (Personally, I think `latest` conveys the intended meaning with more clarity, but I don't like the way Node/npm deals with language and community conduct)
This kind of thinking has no place in serious software development.
After using yarn for a week, I can't imagine going back to npm. I use npm 90% for install, and yarn does this so much better. Installs are 3-4 times faster. Output is minimal and readable (compared to npm's wall of text that I never read). Packages are cached so I can work with slow connections in coffee shops. Sorry to be blunt, but I feel none of the release features gonna help my daily usage of npm. How about actu…
Except now there's another competing standard in the JavaScript world. How long until a feature is added to Yarn and not NPM or vice versa, and a package only works in one of them? I don't mean to be rude, but your last paragraph comes across a bit strange, it sounds like you have a sense of entitlement to having NPM work the way you want. The project is open source, you can fix it, send a pull request, and the whole…
Yeah right. It's not as easy as "hey here's a big PR that overhauls the install algorithm and caching!" and npm will be like "ok merged". A PR (or series of PRs) like these would stall for months or even longer (just check out the amount of open PRs and issues in the npm repo).
Are the NPM guys working on a parallel download feature to speed things up? Have they even noted it as a feature to be implemented? Speed and pkg locking are the only two features that make me use yarn. If they were in npm then most people wont worry about yarn at all I guess.
Earlier quoted context omitted.
I'm super excited to use yarn but, just a heads up, we hit this pretty severe issue when setting it up for our projects: https://github.com/yarnpkg/yarn/issues/761
And if you are using npm & bower in the same project then this other issue is a show stopper https://github.com/yarnpkg/yarn/issues/616
Earlier quoted context omitted.
It's probably to prevent any association with slavery (i.e. "master" owns slaves ) (Personally, I think `latest` conveys the intended meaning with more clarity, but I don't like the way Node/npm deals with language and community conduct)
Now that's just ridiculous. This kind of thinking has no place in serious software development.