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

51–60 of 155 posts

Re: The Everything NPM Package

#51

Post by ShadowBanThis01 »

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?

I never used Node and went right to Deno, partly because NPM and packages sounded like a mess. So far it has been a good experience.

Re: The Everything NPM Package

#52

Post by charcircuit »

spion wrote: post #32
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.

A softer interpretation is possible. "*" should mean that the dependency cannot unpublish all packages and must have at least one version available.

If someone has an older version in the lock file this will break the build.

Re: The Everything NPM Package

#53

Post by throwitaway1123 »

o11c wrote: post #44
bezier-curve wrote: post #31

Earlier quoted context omitted.

> There's a reason I still am skeptical of calling client-side devs "actual programmers". Nothing in your comment actually supports this last jab at web developers. Can you elaborate? I imagine you can't because you're arrogantly posturing.

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.

Re: The Everything NPM Package

#54

Post by baz00 »

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 to the developers results in importing more packages thus adding to the burning tyre fire.

And after several hours of builds and 9000 layers of packages you wake up one morning and in that 50 meg chunk of javascript that is excreted from the process, someone managed to inject a "Slava Ukraini!" banner into your web app.

Re: The Everything NPM Package

#55

Post by int_19h »

Uehreka wrote: post #37
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.

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

Re: The Everything NPM Package

#56

Post by int_19h »

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…

The problem with this argument is that JS also has many horrible API designs. That seem to be replaced by equally horrible API designs, just with a faster churn.

Meanwhile, the horrible C++ and Python API designs at least offer the needed functionality, even if the code looks ugly.

Re: The Everything NPM Package

#57

Post by int_19h »

notnmeyer wrote: post #25
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?

i don’t know how you fix this for js, but in general i think well designed and robust standard libraries are a great place to start. the community shouldn’t need to write a bunch of tiny utility packages to do common things. in other words, make it easier to avoid the deeply nested dependency mess that js encourages.

This problem is a symptom of "move fast, break things" mentality that pervades the JS (and, more broadly, the web) ecosystem. The result is an ecosystem that is specifically optimized for moving fast and breaking things - which is a lot easier when the stable core is tiny.

Re: The Everything NPM Package

#58

Post by int_19h »

charcircuit wrote: post #4
navtoj wrote: post #2

NPM still hasn't fixed the "*" package version bug on their end. https://www.youtube.com/watch?v=IzqtWTMFv9Y&t=465

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.

Re: The Everything NPM Package

#59

Post by ploxiln »

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?

Don't allow un-publishing package versions. If they are literally malware, they can be manually removed by npm admins. If a court orders a takedown due to copyright, that's also something npm admins can handle. If you want to be able to un-publish, then just publish on your own server (or github etc).

If analyzing the dependencies for showing in the NPM web UI, while analyzing, as you exceed 40 direct or transitive dependencies, abort and highlight this package in red, for having excessive dependencies.

If installing locally, you get what you get, don't install random or crazy packages, stick to well known high-quality minimal-dependencies packages. nodejs does include file reading and writing, http server, http client, json ... that will take you pretty far. Master the basics before getting too fancy. And remember, you don't need some company's client package just to make some http requests to their API.

Re: The Everything NPM Package

#60

Post by strken »

charlie0 wrote: post #10
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?

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 be trusted on the front end because it won't work for x% of your users, and offers a clumsy API on the backend that you'd prefer be wrapped in a helper. Developers learnt that they should reach for a library to e.g. deal with localstorage (because on Safari in private mode the built-in calls throw an error instead of recording your data and discarding it after the tab closes) or make a HTTP request (because node doesn't support fetch yet and you don't want to use the complicated streams and callbacks API from the standard lib) and they propelled that culture forward until everyone was doing it.

Post reply on HN