Live data from Hacker News

The Everything NPM Package

socket.dev

101–110 of 155 posts

Re: The Everything NPM Package

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

The entire reason this is a big deal is that people don't know what their dependencies are. The left-pad incident wasn't a big deal because it was pulled, it was a big deal because no one could easily fix their builds and didn't even know they were depending on it, because it was a dependency of a dependency of a dependency. While it's ridiculous to expect that people will audit every single dependency and sub-depend…

> While it's ridiculous to expect that people will audit every single dependency and sub-dependency

It's not ridiculous at all. Professional programmers should answer for the dependencies they bring into their projects.

Re: The Everything NPM Package

#102
post #80
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.

WASM is explicitly not that. WASM itself has no APIs, it's just an execution envionment.

You may be thinking of WASI?

Re: The Everything NPM Package

#103
post #76

Earlier quoted context omitted.

I know it's five hours later and this question has already spawned dozens of responses, but it's worth thinking and speaking clearly if we're trying to arrive at a solution for something. We can start by saying exactly what we're talking about—how do you make what different? Because you mention npm "and their policies" but then switch gears and talk about "is-odd", which is not a policy issue. It's rather something e…

> Whatever the solution to it might be, vague and fuzzy questions—while magnets for chatter since they can stand in for whatever someone wants to read out of them—are not the way to get there. This is a great line. If HN had a quote of the month or something, this should be nominated for that.

https://news.ycombinator.com/bestcomments ?

edit: more like, https://news.ycombinator.com/highlights

Re: The Everything NPM Package

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

The core of the problem is micro dependencies. It seems in the Javascript ecosystem, developers have no awareness of costs of complexity.

When you wonder whether to add a dependency, you should ask yourself: What are the upsides and downsides of adding this dependency. One downside is always that by adding a dependency, you add a potential security problem, a potential point of breakage, and more complexity.

There are situations where these are well justified. If your dependency is stable, from a trustworthy source, and if it is a functionality that you cannot quickly implement yourself. But if you include a dependency that is effectively one line of code, the question answers itself: The costs of adding a dependency is completely unreasonable. It your list of dependencies grows into the 100s, you're doing something wrong.

Re: The Everything NPM Package

#105
post #16

Earlier quoted context omitted.

The entire reason this is a big deal is that people don't know what their dependencies are. The left-pad incident wasn't a big deal because it was pulled, it was a big deal because no one could easily fix their builds and didn't even know they were depending on it, because it was a dependency of a dependency of a dependency. While it's ridiculous to expect that people will audit every single dependency and sub-depend…

This is why I prefer vendoring dependencies. I have to actually code review them.

I'd be called insane if I suggested it. I work with dotnet and I'd rather not add all the code in newtonsoft json and manually review each line. I mean where does it stop? Why not have everyone in the world code review asp.net and dot net libraries for every single website project at that rate?

Re: The Everything NPM Package

#106
post #15

Earlier quoted context omitted.

Honestly, how go does package management is pretty good.

It's personal tastes perhaps, but I don't find the appeal of packages management in Golang. I find PIP, NPM, RubyGems, Nuget, Cargo,… easier to work with. The go.mod syntax is what it is, and doing updates or fixing conflicts isn't easy. Not having a registry is neat, but I'm also unsure of what is going to happen over time as dependencies may be moved or removed. You can see that with old Maven pom.xml where some de…

This is why you should vendor your dependencies. They are part of your codebase at that point.

Re: The Everything NPM Package

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

Make the cost of reusing software non-zero again.

It doesn't have to be as painful as C++ without package managers, but should make every developer spend about 5~10 minutes labor work for adding each direct dependency, or one minute for each new dependency in the dependency closure.

Re: The Everything NPM Package

#109
post #55

Earlier quoted context omitted.

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.

Writing a key comparison function is not a problem. The problem is that Map does not have any way to use such a thing; it always compares using a predefined equality algorithm that is by-reference for all aggregate data types.

Re: The Everything NPM Package

#110
post #73

Earlier quoted context omitted.

I’ve started thinking package management has too much trust now. Ideally, but probably unpractically, projects should check in their packages like they used to under /lib or /third_party, and be much more suspicious of new package dependencies. Basically, you would need to start accepting that you are responsible for any dependencies you choose to include. Any upstream changes you would need to evaluate and bring in…

If NPM made some tweaks this might become trivial. Keep a node_modules/packagefiles with all the .zips that you commit to your source control. The expanded files can be kept out as they are now recoverable just using zip!

Wouldn’t the opposite be better? I’m not sure you could take advantage of the vast majority of files in the zip files being unchanged if you kept compressed archives.
Post reply on HN