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

81–90 of 155 posts

Re: The Everything NPM Package

#81

Post by floren »

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?

When you use 'go get' to add a package to your Go project, it actually fetches the code through a Google proxy which saves a snapshot of the commit in question. Even if the original source goes away, they should have a copy of every version of the library ever fetched via their tool, and devs can continue to build existing stuff.

(If you don't want Google to see what packages you're fetching, you can also turn this off with an environment variable.)

Re: The Everything NPM Package

#82

Post by LelouBil »

charcircuit wrote: post #69
int_19h wrote: post #58

Earlier quoted context omitted.

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.

That's how crates.io does it with yanked releases.

It's removed from the index, and cargo will only download it using a pre-existing lock file

Re: The Everything NPM Package

#83

Post by chatmasta »

charcircuit wrote: post #24
nosefurhairdo wrote: post #20

Earlier quoted context omitted.

If you use wildcard to specify any version of a dependency you shouldn't be surprised if something breaks.

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

Pinning to a specific version doesn't protect against the author unpublishing that version.

The problem with the `*` bug is that it means you can stop anyone from unpublishing future versions of their package by simply creating a package that depends on it with a `*` identifier and publishing that to the registry.

Re: The Everything NPM Package

#84

Post by jonorsi »

Affric wrote: post #5

What a dissatisfying non-apology of an apology. > First, just want to apologize about any difficulties this package has caused. No rationale. No shame. Just the word “apologize” in a sentence. Who downloaded it though? Surely as a dev if you download such a package it’s on you?

Why does he even need to apologize? If anything, npm should apologize and thank him for revealing a huge issue in their unpublishing policies unmaliciously.

Re: The Everything NPM Package

#85

Post by ironmagma »

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'm sorry, but there is no chance that the automake/autoconf suite of tools has caused less pain than `npm install`.

Re: The Everything NPM Package

#86

Post by spencerchubb »

forrestthewoods wrote: post #45
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.

Your argument seems to be "just write good code instead of bad code". My argument is "the best way for good code to exist is to enable and support multiple options". Because if you have only one option and it's bad then you're screwed with no recourse. C++ and Python have, imho, many horrible API designs and we're stuck with them forever. This is stagnation. Rust has a good standard library and also a large community…

Forgive me for nitpicking your Rust example but you can define your own hashmap that inherits from the standard hashmap, and give it a different hash function. I have done it.

Re: The Everything NPM Package

#87

Post by sroussey »

willy_k wrote: post #80
hnlmorg wrote: post #66

Earlier quoted context omitted.

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

> Wouldn’t it be great if there were a libc in the JS world. Something portable and standardised. I mean, it’s not necessarily “in the JS world”, but WASM is basically that.

No it’s not. Problem right now is that every WASM files pulls in its own stdlib. Which is a waste once you use more than one.

Re: The Everything NPM Package

#88

Post by sroussey »

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.

It’s not key comparison issue:

const idx = [1,2] const m = new Map m.set(idx,"hi!") console.log(m.get(idx)) // outputs "hi!"

console.log(m.get([1,2]) // outputs undefined

That last line has created a new array object, and Map is made to be fast so checks equality by reference. Ah, which is what you to be able to change. I guess you would want to pass a new map a comparator function, so that it does a deep equal. That would be faster than what you would have to do now:

const idx2 = String([1,2]) m.set(idx2, "yo") console.log(m.get(idx2)) // yo console.log(m.get(String([1,2])) // yo

Re: The Everything NPM Package

#89

Post by FireInsight »

ruune wrote: post #22
bsimpson wrote: post #11

Earlier quoted context omitted.

GitHub's support is surprisingly bad. When I was consulting for an R&D lab at eBay, we open sourced a bunch of our work in a GitHub org. It was sanctioned by eBay's OSPO; they even linked to it from their main open source directory. 7 years later, long after the team disbanded, someone in eBay's current legal team decided that the (now archival) org violated eBay's trademarks. For the last year+, every time I've open…

You could probably code up a simple browser extension to hide the banner via CSS if it bothers you a lot. Still only a bad fix that shouldn't be necessary

No need to code anything up. uBo should be enough. And CSS could be injected using Stylus easily.

Re: The Everything NPM Package

#90

Post by quickthrower2 »

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?

Soft deletes. You can delete a package and it stops being advertised but a shadow copy of referenced versions are kept for anything that depends on it. NPM spews warnings when this happens.

Once the referencing packages are updated are deleted or modified the shadow versions can be dropped.

Post reply on HN