But npm is just a distribution channel. People know to apply scrutiny before downloading and running them, but we wouldn't tell people to only run binaries they've hand audited and hand compiled.
-
-
Replying to @tomdale @segphault and
All I'm saying is there isn't anything special about npm or node packages. I think the way to guard against these concerns is to use well-vetted dependencies, not throw the baby out with the bathwater and say "only use dependencies you hand audit."
2 replies 0 retweets 0 likes -
My argument wasn’t to hand audit every release of every package. It was to keep the scope of dependency bloat small enough that you reasonably could. The crazy number of transitive dependencies does make npm different from similar ecosystems
2 replies 0 retweets 0 likes -
Right, but I'd argue that the "small modules philosophy" is problematic because it diffuses trust into a complex web of dependencies, but "can you hand audit?" as a heuristic makes it seem like it's about the size of the code. (I think this is what people are pushing back on.)
1 reply 0 retweets 2 likes -
Replying to @tomdale @segphault and
The V8 codebase is larger than many apps' dependency, but it's a single source of trust. The opaque, diffused web of trust is the issue with small npm packages, not the code size. But the uncomfortable conclusion is that maybe monolithic frameworks weren't so bad after all.
1 reply 0 retweets 2 likes -
I completely agree that there are ways to fix the ecosystem so that my approach wouldn’t be necessary. But I don’t think I’m wrong to say that simply avoiding the huge mess of transitive dependencies is a much safer and more responsible way to consume npm as it exists today.
1 reply 0 retweets 0 likes -
Or maybe rely more on larger, more curated collections of dependencies that are vetted by responsible groups. (as
@tomdale is hinting at, we call these collections "frameworks"
)2 replies 1 retweet 9 likes -
Using a framework doesn't help if one of that framework's dependencies brings in a ton of other transitive dependencies that are all moving independently of the framework that nobody responsible for the framework is really vetting.
1 reply 0 retweets 0 likes -
As a framework author, I can tell you that we vet transitive dependencies more than you might expect.
1 reply 0 retweets 0 likes -
Well, I feel a lot more comfortable using the ~700 package ember-cli knowing that you're personally reviewing all of those transitive dependencies. ;-)pic.twitter.com/IWz4AL1Y1n
4 replies 0 retweets 1 like
Not sure if I should treat this as a troll or keep trying to draw comparisons to other projects you think you trust. Like how many lines of third party code do you think are included in Chrome or Firefox, for example.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.