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

41–50 of 57 posts

Re: NPM v4.0.0

#41

Post by joshstrange »

ceejayoz wrote: post #39
po1nter wrote: post #15

Earlier quoted context omitted.

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.

Re: NPM v4.0.0

#42

Post by joshstrange »

ceejayoz wrote: post #40
Longhanks wrote: post #36

Earlier quoted context omitted.

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.

Re: NPM v4.0.0

#43

Post by bsimpson »

madeofpalk wrote: post #4
Lx1oG-AWb6h_ZG0 wrote: post #2

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

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.

Re: NPM v4.0.0

#44

Post by coldtea »

raindev wrote: post #26
coldtea wrote: post #23

Earlier quoted context omitted.

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

Re: NPM v4.0.0

#45

Post by coldtea »

raindev wrote: post #29
coldtea wrote: post #24

Earlier quoted context omitted.

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

Re: NPM v4.0.0

#46

Post by ceejayoz »

joshstrange wrote: post #42
ceejayoz wrote: post #40

Earlier quoted context omitted.

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

Re: NPM v4.0.0

#47

Post by dictum »

joshstrange wrote: post #42
ceejayoz wrote: post #40

Earlier quoted context omitted.

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

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.

Re: NPM v4.0.0

#48

Post by steveklabnik »

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"

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

Re: NPM v4.0.0

#50

Post by gotofritz »

joshstrange wrote: post #41
ceejayoz wrote: post #39

Earlier quoted context omitted.

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.
Post reply on HN