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

The Everything NPM Package

socket.dev

Post reply on HN
Print view View original

61–70 of 155 posts

Re: The Everything NPM Package

#61

Post by cybrox »

baz00 wrote: post #54
superasn wrote: post #7

I've seen a lot of people criticise npm and their policies but I've never come across a solution. Npm has its flaws and while there are such abuses like everything package, is-odd, left-pad, etc there are also many useful packages like vue, sortable, etc without which development will be a huge pain. So not asking rhetorically, if we had all the insight and knowledge we have now, how would you make it different?

Personally I would like it and the ecosystem to just cease to exist overnight. Nothing on earth has caused so much pain, misery, suffering and agony, apart from possibly PHP. Our devops guys scream from the seething pain whenever the have to debug some pile of shit that decides it won't build unless all the runes are aligned precisely and all the RAM in the universe is available on the build runners. And pushing this…

I mean... just don't install everything then?

Over-reliance on third party dependencies is a choice. One could argue that it's unreasonable not to do it if you want to stay competitive but good luck changing human nature then. If there are shortcuts, they will be taken.

Re: The Everything NPM Package

#62

Post by strken »

richbell wrote: post #49
SahAssar wrote: post #38

Earlier quoted context omitted.

So could you list those problems?

Namespaces, for one.

Namespaces in Maven seem like they're clunky. The pseudo-DNS thing where the first section is an actual domain but the second is whatever you want is quite janky, as is not matching the namespace to the package. Plus domains are transferable themselves and it seems like a bad idea to use them as identifiers.

Not to say that npm shouldn't have had namespaces by default, but I think there's good reason not to blindly do everything the way the Java community did.

Re: The Everything NPM Package

#63

Post by hnlmorg »

MetaWhirledPeas wrote: post #26
charlie0 wrote: post #17

Earlier quoted context omitted.

I don't see how creating a definitive sorting library is stagnation compared to having 10 mediocre libraries that are all missing some sort of critical functionality.

Because who is going to bother working on any packages if they risk rejection in the end? Have fun with your ______ package because it's never going to improve.

There’s plenty of languages with vast standard libraries and which also have 3rd party libraries that offer the same feature as something in stdlib but more enhanced against a specific metric.

You see it in Go, Python, .NET, etc.

Re: The Everything NPM Package

#64

Post by moritzwarhier »

int_19h wrote: post #55
Uehreka wrote: post #37

Earlier quoted context omitted.

> I don't need 12 different implementations for sorting on Vue/React/[insert spa framework of the month]. This feels like a bit of a strawman, since sorting is already in the standard library and there aren’t in fact popular sorting packages for each framework (that would in fact be ridiculous). If you want to start a real debate though, bring up date/time pickers. There are multiple date picker, time picker and date…

There are still so many basic things that aren't in the JS stdlib, though. A good example is Map - if you need to use a tuple of two values as a key, you're SOL because there's no way to customize key comparisons. Hopefully we'll get https://tc39.es/proposal-record-tuple/ eventually, but meanwhile languages ranging from C++ to Java to Python have had some sensible way to do this for over 20 years now.

There is a trivial way to have custom key comparisons: write a function that returns the key you want. You can implement equals() using some kind of serialization, or using a lookup table of references - whatever you want!

Of course, Records and Tuples would greatly simplify the process.

Re: The Everything NPM Package

#65

Post by cperciva »

superasn wrote: post #7

I've seen a lot of people criticise npm and their policies but I've never come across a solution. Npm has its flaws and while there are such abuses like everything package, is-odd, left-pad, etc there are also many useful packages like vue, sortable, etc without which development will be a huge pain. So not asking rhetorically, if we had all the insight and knowledge we have now, how would you make it different?

how would you make it different?

Have smarter users. If your package breaks because it depends on trivial code which got deleted, you shouldn't have depended on that in the first place.

Preventing people from deleting their code -- always, or even just sometimes -- was never the right solution.

Re: The Everything NPM Package

#66

Post by hnlmorg »

strken wrote: post #60
charlie0 wrote: post #10

Earlier quoted context omitted.

Devs working with core developers to create more 1st party packages would be a good start. I don't need 12 different implementations for sorting on Vue/React/[insert spa framework of the month]. I just need 1 really good sorting library. With it, we can move to less overall dependencies on random packages.

There are two massive reasons why js got here, with a million packages for tiny things and a culture of using them: browser cross-compatibility requiring complicated workarounds for easy-seeming tasks, and the introduction of promises + async/await to node.js after the standard library already used callbacks. When you combine those together you end up with a situation where "normal" js code not from a library can't b…

Modern JavaScript reminds me a lot of BASIC, Pascal and other 70s and 80s languages. Even C pre-ANSI.

We’ve been blessed in recent years that either languages are fully open source and come with a reference implementation, or a standards body governs the implementation detail. Sometimes even both.

Whereas JavaScript is really more a group of languages, each with their own implementation quirks.

ECMA was intended to bring some sanity to all of this. And it’s definitely better than it was in the JScript days of IE vs Netscape. But there isn’t anything (that I’m aware of) that defines What should be a part of the JavaScript standard library.

Wouldn’t it be great if there were a libc in the JS world. Something portable and standardised.

Re: The Everything NPM Package

#67

Post by o11c »

throwitaway1123 wrote: post #53
o11c wrote: post #44

Earlier quoted context omitted.

Programming is, fundamentally, the imposition of a chosen order upon the world. You can easily distinguish somebody who's new to programming by the lack of choosing or the lack of effective order, and I think it quite fair to call them "not yet a programmer" while they're in that phase. Sure, theoretically web devs can be programmers. But in practice, choice is overwhelmed by happenstance, and/or order does not follo…

This is a vague statement filled with poetic language that conveys very little useful information. I can't imagine trying to parse this as a non-native English speaker and extract any sort of meaningful information from this comment.

Okay, by example then:

* if you just bash on the keyboard randomly until you get a result, or just copy-paste from StackOverflow, or just let an LLVM spew something, that's not programming - there's no choice.

* if you do deliberately choose something, but your choice fails to produce a meaningful result, that's not programming - there's no order.

Re: The Everything NPM Package

#68

Post by Aeolun »

scubbo wrote: post #50
charcircuit wrote: post #24

Earlier quoted context omitted.

The same can be said about not pinning to a specific version as even some patch releases can break things or change performance characteristics.

This, to me, is still one of the most astonishing things about the JavaScript ecosystem that everyone just accepts.

What is your suggestion for improving it? I can accidentally publish a breaking bug in my patch release, and I might not notice.

Re: The Everything NPM Package

#69

Post by charcircuit »

int_19h wrote: post #58
charcircuit wrote: post #4

Earlier quoted context omitted.

It's intentional and is not a bug. "Fixing" it could cause someone's build to break by someone unpublishing a version.

As this package clearly demonstrates, it's a broken design.

The way unpublishing works is broken. It would be better if unpublish would just hide the version. Then it would not matter if someone unpublished something with dependencies.

Re: The Everything NPM Package

#70

Post by technion »

cperciva wrote: post #65
superasn wrote: post #7

I've seen a lot of people criticise npm and their policies but I've never come across a solution. Npm has its flaws and while there are such abuses like everything package, is-odd, left-pad, etc there are also many useful packages like vue, sortable, etc without which development will be a huge pain. So not asking rhetorically, if we had all the insight and knowledge we have now, how would you make it different?

how would you make it different? Have smarter users. If your package breaks because it depends on trivial code which got deleted, you shouldn't have depended on that in the first place . Preventing people from deleting their code -- always, or even just sometimes -- was never the right solution.

I know "have smarter users" sounds like a joke but a lot of the problem really is cultural. In most languages you would write a two line leftpad function, in the js world everyone will tell you you're doing it wrong and should use a library.
Post reply on HN