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

Npm v5.0.0 released

blog.npmjs.org

Post reply on HN
Print view View original

71–80 of 117 posts

Re: Npm v5.0.0 released

#71

Post by mstade »

diggan wrote: post #62
tiles wrote: post #32

Earlier quoted context omitted.

What replaces the npm registry, though? That's the reason that npm Inc. exists, not just stewardship of the CLI.

A decentralized repository of packages that anyone can help out maintain. Not entirely sure how, but I think that would be the ideal scenario.

Something like IPFS could perhaps be used for this. I think the biggest issue is probably access control. I.e. just releasing packages addressed by content isn't enough, because people generally depend on @whatever/left-pad and not 5b055a0b42f1c or whatever the hash may be. Real estate in a global name space means someone gets there first, so you'll need to consider how to deal with name squatters and the likes. With a centralized source like npm it's as easy as getting in touch with support (they're very good) but when no one knows the name space everyone owns the name space – makes it hard to make things "nice".

So I guess what I'm saying is that just storage isn't the tricky bit to distribute really, but having a global namespace is I guess.

Re: Npm v5.0.0 released

#72

Post by rattray »

chrisweekly wrote: post #10

First of all: Thank you, yarn, for helping the community see the naked emperor. Deterministic builds by default are such an obvious (in retrospect) core requirement. Couple questions: Question 1: Does anyone else who's been around more than a couple years share my view that Yarn : NPM :: IO.JS : Node? IOW: healthy competition, catalyst for necessary change, ultimately a bridge or stopgap. Question 2: Any good compreh…

As @pluma mentioned, a "merge" seems unlikely (for one thing they don't share much, if any, code).

However, npm could certainly compete with more of yarn's features (fast local cache[0], shorter syntax for running scripts like `npm start`, etc)

[0] turns out they did that: https://twitter.com/maybekatz/status/865393382260056064 wow!

Re: Npm v5.0.0 released

#73

Post by mstade »

evolve2k wrote: post #54

> A new, standardised lockfile feature meant for cross-package-manager compatibility (package-lock.json) Surely it would be much better to follow standard lock file naming conventions and name the file package.lock

It bothers me somewhat that they say this is standardized, but not by whom. Is the idea that Yarn should fall in line or is it a case of https://xkcd.com/927/ ?

Re: Npm v5.0.0 released

#74

Post by 2manyredirects »

We dropped npm in favour of yarn a while back, but I imagine we'll switch back once the stable release is out. Our needs are perhaps simpler than most, but the key issues we were having with npm at the time were directly solved by yarn:

  1. Dependency install was taking too long.
  2. Inconsistent builds between devs because of no lock file.
  3. Could not search the registry from the command line in a timely manner.
Having just done a quick test on a random project, I'm pleased to see that all of those concerns are now taken care of, plus the install (for this project at least) is ~30% faster than it is with yarn.

Re: Npm v5.0.0 released

#75

Post by draw_down »

chrisweekly wrote: post #10

First of all: Thank you, yarn, for helping the community see the naked emperor. Deterministic builds by default are such an obvious (in retrospect) core requirement. Couple questions: Question 1: Does anyone else who's been around more than a couple years share my view that Yarn : NPM :: IO.JS : Node? IOW: healthy competition, catalyst for necessary change, ultimately a bridge or stopgap. Question 2: Any good compreh…

Yeah, I think that's a good comparison, except the upsides of yarn seemed much more obvious to the community than was the case with IOJS. There seemed a lot less controversy than with IOJS.

What a time those days were, feels like a million years ago already.

Re: Npm v5.0.0 released

#76

Post by JeuelyFish »

plexicle wrote: post #60

npm desperately needs a flat install option.

This is probably a naive question, but the only use case I've come across of needing a flat-install option was to use Polymer.js web components (which is why so much of the polymer project relies on bower).

Aside from that, what is the use case that flat installs solve?

Re: Npm v5.0.0 released

#77

Post by plexicle »

JeuelyFish wrote: post #76
plexicle wrote: post #60

npm desperately needs a flat install option.

This is probably a naive question, but the only use case I've come across of needing a flat-install option was to use Polymer.js web components (which is why so much of the polymer project relies on bower). Aside from that, what is the use case that flat installs solve?

Not naive, and that's pretty much the primary reason. But for all web components in general, not just the Polymer flavor.

Re: Npm v5.0.0 released

#78

Post by eropple »

jbverschoor wrote: post #40
tiles wrote: post #36

Earlier quoted context omitted.

npm has to deal with scale: it's now the largest programming language package manager, and most project dependency trees have exploded in size as a result. Optimizing that led to yarn and to npm@5.

npm has to deal with scale because every single npm install goes to npm instead of a local cache of certain versions. Bundler led to yarn. The JS community should start looking what other ecosystems do and have done (right and wrong). Such a waste of time these past 20 years and it happens over and over.

I could be incorrect, but I don't believe Bundler was the first to lock and manage dependencies? I seem to recall using such tools before 2010. This isn't to take away from your main point by any stretch; only recently has JavaScript gone from "downright terrible" to "tolerable" and most of it is through doing what others already did, better, many years before. It still feels like a lot of the community doesn't have sufficient exposure to stuff outside their closure and people who work with that community's stuff are the worse for it.

Re: Npm v5.0.0 released

#79

Post by diggan »

mstade wrote: post #71
diggan wrote: post #62

Earlier quoted context omitted.

A decentralized repository of packages that anyone can help out maintain. Not entirely sure how, but I think that would be the ideal scenario.

Something like IPFS could perhaps be used for this. I think the biggest issue is probably access control. I.e. just releasing packages addressed by content isn't enough, because people generally depend on @whatever/left-pad and not 5b055a0b42f1c or whatever the hash may be. Real estate in a global name space means someone gets there first, so you'll need to consider how to deal with name squatters and the likes. With…

well, you could depend on left-pad@5b055a0b42f1c, and the name doesn't really matter. Normally you would include that as require('left-pad') but if you have multiple versions, I don't see why require('left-pad@5b055a0b42f1c') couldn't be used. There is a tool for doing this in Golang already[0] and I've also done some experiments to get this to work in JavaScript[1]

- [0] https://github.com/whyrusleeping/gx

- [1] http://everythingstays.com

Re: Npm v5.0.0 released

#80

Post by ceejbot »

jbverschoor wrote: post #40
tiles wrote: post #36

Earlier quoted context omitted.

npm has to deal with scale: it's now the largest programming language package manager, and most project dependency trees have exploded in size as a result. Optimizing that led to yarn and to npm@5.

npm has to deal with scale because every single npm install goes to npm instead of a local cache of certain versions. Bundler led to yarn. The JS community should start looking what other ecosystems do and have done (right and wrong). Such a waste of time these past 20 years and it happens over and over.

This statement is false and has been since the very first work done on the npm cli. npm has, in every version of it that has ever existed, since before there was even a package registry, installed preferentially from its local cache of packages where possible.
Post reply on HN