NPM v4.0.0 | Hacker News Reader

NPM v4.0.0

github.com

113 pointsJarlakxen56 comments

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 actually fixing the tab completion, which has been slow and broken forever?

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

Yeah I wouldn't use it in production until it becomes more stable. However the team behind it seems to iterate really fast. Look at the issues fixed between public release and 0.16[0], which is only 7 days.

[0]: https://github.com/yarnpkg/yarn/releases/tag/v0.16.0

I've been using it in production for a large app for the past week and it's been great. CI is faster, deploying is faster and dev is faster.

Likewise, can't wait for yarn to finish its growing pains, until then it's still npm.

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

Out of curiosity, why use npm and bower in the same project?

Not op but I'll chime in. My team uses npm for our build tools and bower for our frontend libraries (moment, chats, lodash, etc). Our re-write only uses npm but at the time (and possibly even now) there were frontend libraries that only provide bower packages and bower seemed like the right tool for the job anyways.

It doesn't sound ideal having two tools that do pretty much the same thing, you are just adding a potential extra point of failure. Migrating from bower to npm is incredibly easy.

How would you migrate libraries that are only on bower, not npm?

How many of those are a) left and b) still maintained?

If there are still any in 2016 it's a good sign they are not begin actively maintained

I remember wondering this same thing myself when Bower was the the new hotness.

"Don't I already have a tool that does exactly this?"

It seem to ignore shrinkwrapped packages as well: https://medium.com/@boennemann/avoid-yarn-for-packages-and-f...

It looks like they want to just eat bower. Tbh, if webpack or browserify can eat a tooling & dev stack, and yarn can eat bower and do package management, it would be a nice workflow.

I wouldn't want 1 tool to rule them all, but a single tooling/dev/task kit and a single dependency/pckg manager would be nice.

I went to DuckDuckGo to check out what yarn is. The front page makes no mention of JavaScript at all (at least on mobile). Accordingly to DuckDuckGo the whole site mentions "JavaScript" only three times. The same is true about the GitHub readme: no mentions of JavaScript at all. Before praising something, makes sense to tell people what it is.

/rant

Thanks for the highlight, I use npm solely for global installs, will give yarn a try.

Yarn has been the talk of the dev world for the last week man. It had a large upswing on both here and reddit.

Not everyone reads news all the time.

> Before praising something, makes sense to tell people what it is.

I don't know where you've been but anyone who is even remotely invested in the npm ecosystem probably knows what Yarn is at this point.

This is irrelevant. You may be just a new comer, or not a professional developer, and still want to use yarn. A clear website seems a basic requirement to me for any project.

>A clear website seems a basic requirement to me for any project.

Well, you can't always depend on that, and in the end of the day, nothing beats actually researching and asking around.

The GNU tools have some of the worst webpages -- and yet they are some of the most useful, and commonly used, packages.

Let's take a look at GNU tar [1] and GNU social [2] webpages as examples. The first thing they tell a user is what the project is. I would say, both of them are order of magnitude better than the yarn homepage.

1. https://www.gnu.org/software/tar/ 2. https://gnu.io/social/

>GNU Tar provides the ability to create tar archives

Really descriptive.

>I went to DuckDuckGo to check out what yarn is.

And DuckDuckGo (mentioned twice in the comment) is relevant because?

Because DuckDuckGo's index of the yarn's website could be screwed or out of date. Also, because people communicate using language, not axioms.

>Because DuckDuckGo's index of the yarn's website could be screwed or out of date.

And why should we know about DDG's index info about Yarn?

Just visit Yarn's actual project site (which is what you're supposed to be criticizing), and focus your critique on what's actually there now.

>Also, because people communicate using language, not axioms.

So? How does that justify adding off-topic/redundant information on one's critique?

I used DDG too, Generally, one would search for something like "yarn npm" in which case it is like the second link is the yarn homepage and the first link is a npm vs yarn post. DDG isn't as good as Google in figuring out context because it doesn't assume you are a programmer because it doesn't track or bubble you.

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 community will benefit. I wonder if it would have been better if the Yarn developers would had done the same.

I don't agree with the whole "it's open source, so if you don't fix it yourself you're just being entitled".

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.)

Your argument is valid, but I think you misunderstood my point. I'm not saying that you have to fix it, just that you can. And you/we should take advantage of that.

We as developers can work together on open source projects, and make them better for everyone. It's not like closed source software where the choices are a) use a competing product or b) write our own. And by work I don't mean just writing code: writing documentation and even reporting issues is just as valuable.

It seems to me that the JavaScript community is very quick to say "this is s..t, I can do better!" and throw away all the work someone has done and reimplement it from scratch. Sometimes developers take criticism very badly, so I agree it isn't always an possible to say "how about you try this", and I agree sometimes the code is beyond saving and it is better just to start afresh. But as someone who is mainly an outsider to the community, it seems like there is very much an epidemic of NIH syndrome, and people aren't even willing to try contributing.

Maybe you are right about my sense of entitlement, but I do truly believe if we would work together more and be less self-centred, society would benefit greatly from it.

I don't think I misunderstood your point at all. Your comment here seems to be splitting hairs between whether I think that you are claiming that you "have to" fix things or whether you are claiming we "should" fix things. I don't think that the distinction between "have to" or "should" is particularly relevant.

You're right that the JS community is quick to dump a project. You're also right that sometimes code is beyond saving and it's better to start afresh. As someone who claims to be an outsider to the JS community, maybe you don't understand just how broken NPM is, and how much we welcome the appearance of something like Yarn.

This is the real beauty of having a separate package repository and package manager, and the beauty of open source software when it's made out of components with well-defined interfaces. Yarn can still use the NPM repository, but Yarn will suffer from far fewer of the deficiencies that NPM has. The exact same thing has happened in other communities many times. Haskell went from Cabal to Stack, Python went from easy_install to pip, and most Linux distros have been through their fair share of package managers. As someone who has personally migrated from Cabal to Stack and from easy_install to pip, the change from NPM to Yarn seems familiar.

Or in other words, the replacement of NPM (the package manager) with Yarn is a healthy thing that is happening for good reasons (because reporting issues, writing documentation, and submitting PRs will not make NPM do what you want, and saying that we "should" do those things is wrong).

Often times I see this argument made, and on it's face seems like a good one.

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.

> 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.

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).

Yarn may be something worth investing time in, but in the announcement blog post I found this part exceedingly ridiculous:

"The easiest way to get started is to run: npm install -g yarn"

They also have binaries you can install without npm, however, it's extremely likely that their target audience already has npm installed, so that is indeed the easiest.

(Also, something something "easy_install pip" or "gem install bundler")

It's a drop-in replacement for an audience who almost certainly have npm already. Path of least resistance for your audience is where you should be.

> Keep an eye out for npm@5 in Q1 2017. We're planning a major overhaul of shrinkwrap as well as various speed and usability fixes for that release.

So the most interesting part of npm4 release are the announced improvements that are coming in npm5 :)

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.

I would think they would have to solve the deterministic installation problem first.

> npm's default git branch is no longer `master`. We'll be using `latest` from now on.

Is there any reason to do this?

By quick glance at their repository branches, it doesn't seem like they're using any kind of dev/el/op branch what makes me think that their development might have been happening in master branch (mind, this is me guessing without any knowledge about NPM's development process, so I might be totally and utterly wrong) and this could lead to some issues from people, who would expect master to be always-correct-and-working branch with all the newest and possibly breaking changes happening somewhere else.

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.

"Spending 30 seconds renaming a branch saves us potential PR issues" is somehow dangerous thinking?

They didn't say dangerous, they said ridiculous and it is a ridiculous guess. I don't really agree with "This kind of thinking has no place in serious software development." part but the assertion that the change is "probably to prevent any association with slavery" is ridiculous.

It's not a crazy assertion.

https://github.com/django/django/pull/2692

I don't see a reason to get all fussed about a terminology change that hurts no one and prevents upset, though.

In addition to the link ceejayoz posted, here are some other instances of this complaint:

https://www.drupal.org/node/2275877

https://github.com/rust-lang/rust-buildbot/issues/2

https://github.com/antirez/redis/issues/3185

I just mentioned it because I notice a greater sensitivity about language in the npm community, e.g. never using gendered language.

I don't share the view that "master" somehow endorses or minimizes slavery.

My speculation: it matches the dist tag.

NPM is so Oct 10 2016.

That attitude is so Javascript-shallow.

I'm glad for the relatively low amount of breaking changes this time. npm prepare should be a nice addition (using prepublish for, e.g., installing typings is such a non obvious hack).

That said, I'm still not certain about shrinkwrap excluding dev deps. I mainly use it to ensure my build agent uses the same dependencies as my dev box, and at a time when things like babel pull in a ridiculous amount of sub dependencies, it really does not make sense to not lock down _all_ your dependencies by default.

The difference between regular dependencies and devDependencies is very blurry with things like Webpack and Babel - they're not required at runtime but they're responsible for significant amounts of runtime.

Luckily, npm shrinkwrap accepts a --dev option to include devDependencies

Ask yourself "will authors consuming my module need this dependency?". If not, it's a development dependency.

If you're including pure-JavaScript artifacts in your npm releases, downstream authors probably don't care about your Babel/Webpack configuration.

npm search will at least return results now ahah. I didn't know about https://npm.im/npms-cli , sounds like a great alternative. Thanks for sharing this release here :)

> npm scripts no longer prepend the path of the node executable used to run npm before running scripts. A --scripts-prepend-node-path option has been added to configure this behavior.

Why? That seems like a good default, something most people would need.

It's explained 2 paragraphs bellow

Reply on news.ycombinator.com