Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NPM v4.0.0

github.com

Post reply on HN
Print view View original

51–57 of 57 posts

Re: NPM v4.0.0

#51

Post by Sacho »

gotofritz wrote: post #50
joshstrange wrote: post #41

Earlier quoted context omitted.

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?

Re: NPM v4.0.0

#52

Post by lucaspiller »

klodolph wrote: post #33
lucaspiller wrote: post #32

Earlier quoted context omitted.

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…

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 co…

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.

Re: NPM v4.0.0

#53

Post by ceejayoz »

Sacho wrote: post #51
gotofritz wrote: post #50

Earlier quoted context omitted.

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?

Re: NPM v4.0.0

#54

Post by klodolph »

lucaspiller wrote: post #52
klodolph wrote: post #33

Earlier quoted context omitted.

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 co…

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 d…

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

Re: NPM v4.0.0

#55

Post by cr3ative »

otar wrote: post #34
octref wrote: post #5

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…

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"

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.

Re: NPM v4.0.0

#56

Post by ferentchak »

gotofritz wrote: post #50
joshstrange wrote: post #41

Earlier quoted context omitted.

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.

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?"

Re: NPM v4.0.0

#57

Post by gotofritz »

Sacho wrote: post #51
gotofritz wrote: post #50

Earlier quoted context omitted.

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?

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