Always Review Your Dependencies, AGPL Edition • Hacker News Board

Re: Always Review Your Dependencies, AGPL Edition

#221

Post by lmm » Tue, Jan 07, 2020, 2:28 AM UTC

mcguire wrote: post #197

lmm wrote: post #98

Earlier quoted context omitted.

Dependencies are cattle, not pets. There's nothing wrong with having zillions of them; what you need is good tools to manage them in bulk. In the JVM ecosystem, projects are only allowed in the Maven Central repository if they have their license documented in a machine readable fashion there; it's then trivial to check what licenses you're depending on (and there are several plugins available for doing so). I'm amaze…

Does Maven Central also require machine-checkable proofs of security?

No (and I don't think any code repository does or could; what would a "proof of security" actually prove?). It does require machine-checkable signing of all releases.

Re: Always Review Your Dependencies, AGPL Edition

#222

Post by damnyou » Tue, Jan 07, 2020, 4:02 AM UTC

vmchale wrote: post #216

damnyou wrote: post #205

Earlier quoted context omitted.

Do you mean passing a struct from e.g. clap 2 into clap 3? Yeah that won't work directly, nor should it in my opinion. If it is frequently required, projects can and should provide a compatibility layer which does any necessary conversions.

> Do you mean passing a struct from e.g. clap 2 into clap 3? Yeah that won't work directly, nor should it in my opinion. I agree! But it shouldn't fail at compile time with a vexing error message. It should fail to resolve dependencies when calculating a build plan.

That would seem to completely disallow any compatibility layers, which seems like a bad outcome. Unless you had some sort of solution in mind for that?

I agree that the error message sucks, for what it's worth.

Re: Always Review Your Dependencies, AGPL Edition

#223

Post by choeger » Tue, Jan 07, 2020, 6:36 AM UTC

gpvos wrote: post #103

choeger wrote: post #2

That's the hidden cost of npm, cargo, pip, et. Al. The other one is IMO akin to overweight. Try to modernize a mid-sized project after one or two years and cry when you see the dependency graph. Ceterum censeo go inferior est.

> Ceterum censeo go inferior est. Cur?

Because it did not even bother with a powerful and useful type system. Counter example: Rust. I don't think go would be a thing if rust was, say, two years older than it is.

Re: Always Review Your Dependencies, AGPL Edition

#224

Post by choeger » Tue, Jan 07, 2020, 6:37 AM UTC

lifthrasiir wrote: post #31

choeger wrote: post #2

That's the hidden cost of npm, cargo, pip, et. Al. The other one is IMO akin to overweight. Try to modernize a mid-sized project after one or two years and cry when you see the dependency graph. Ceterum censeo go inferior est.

If you define the "modernization" as mindlessly switching to a trending framework or library, the cost is inevitable even without package managers.

I define modernization as anything from updating frameworks, over libraries, tools, to the language itself.

Re: Always Review Your Dependencies, AGPL Edition

#225

Post by marcus_holmes » Tue, Jan 07, 2020, 7:58 AM UTC

flanbiscuit wrote: post #209

Lammy wrote: post #196

Earlier quoted context omitted.

What are you using instead of Webpack? I have a very old personal project still using Webpack 2 and would love a simpler alternative that isn’t just downloading library dist files and checking them in to my project repo. I don’t even need babel or minification or any of that, just simple dependency version management and fetching.

I switched to Rollup for a project and liking it so far, also less dependencies: Here's a comparison of popular bundlers using a visualization tool I found online: Webpack - https://npm.anvaka.com/#/view/2d/webpack Parcel - https://npm.anvaka.com/#/view/2d/parcel Rollup - https://npm.anvaka.com/#/view/2d/rollup Granted this only covers the initial package for each of these, there are usually a bunch of extra plugins…

I'm wedging together Vue components by abusing the Go templating engine at the moment.

But it's not satisfactory because I can't unit test my components properly, or minify/obfuscate properly.

I'm looking at browserify to help with that, but that's going to break my whole build system so I need to find the appropriate time to do that.

Or there's Elm... I keep looking at Elm and wondering if that would solve a lot of these problems...

Re: Always Review Your Dependencies, AGPL Edition

#226

Post by tastroder » Tue, Jan 07, 2020, 10:18 AM UTC

mattigames wrote: post #36

tastroder wrote: post #30

Earlier quoted context omitted.

This comes up pretty often, what would you like to see in such a standard library? I consider the libraries included in Node pretty extensive these days.

Node is a tiny part, the big fish is JavaScript in the browser

The person I replied to compared the stdlib to that of PHP and Python, both of which are backend components. Frontend land is getting frequent updates already, with a relatively good process, vendor backing and incubation in browsers, not sure what the complaint is supposed to be there? That it's too slow? Imho that's a good thing when it comes to most language changes.

Re: Always Review Your Dependencies, AGPL Edition

#227

Post by mattigames » Tue, Jan 07, 2020, 3:32 PM UTC

tastroder wrote: post #226

mattigames wrote: post #36

Earlier quoted context omitted.

Node is a tiny part, the big fish is JavaScript in the browser

The person I replied to compared the stdlib to that of PHP and Python, both of which are backend components. Frontend land is getting frequent updates already, with a relatively good process, vendor backing and incubation in browsers, not sure what the complaint is supposed to be there? That it's too slow? Imho that's a good thing when it comes to most language changes.

Yeah is too slow, but is not only that, is that it makes senses for it to exist years on user-land as a library (or multiple ones) before being implemented on any standard.

Re: Always Review Your Dependencies, AGPL Edition

#228

Post by Lammy » Tue, Jan 07, 2020, 8:14 PM UTC

flanbiscuit wrote: post #209

Lammy wrote: post #196

Earlier quoted context omitted.

What are you using instead of Webpack? I have a very old personal project still using Webpack 2 and would love a simpler alternative that isn’t just downloading library dist files and checking them in to my project repo. I don’t even need babel or minification or any of that, just simple dependency version management and fetching.

I switched to Rollup for a project and liking it so far, also less dependencies: Here's a comparison of popular bundlers using a visualization tool I found online: Webpack - https://npm.anvaka.com/#/view/2d/webpack Parcel - https://npm.anvaka.com/#/view/2d/parcel Rollup - https://npm.anvaka.com/#/view/2d/rollup Granted this only covers the initial package for each of these, there are usually a bunch of extra plugins…

Rollup looks like it would fit my needs perfectly. Thank you!

Re: Always Review Your Dependencies, AGPL Edition

#229

Post by tastroder » Wed, Jan 08, 2020, 8:04 AM UTC

mattigames wrote: post #227

tastroder wrote: post #226

Earlier quoted context omitted.

The person I replied to compared the stdlib to that of PHP and Python, both of which are backend components. Frontend land is getting frequent updates already, with a relatively good process, vendor backing and incubation in browsers, not sure what the complaint is supposed to be there? That it's too slow? Imho that's a good thing when it comes to most language changes.

Yeah is too slow, but is not only that, is that it makes senses for it to exist years on user-land as a library (or multiple ones) before being implemented on any standard.

For what it's worth, I don't think that's a bad thing. Assuming you're talking about jQuery and the like, what was adopted to the specifications is the consensus of many years and wouldn't have been predictable in the first few of that library's history. I mean, frontend land is incredibly fragmented and browsers are no operating systems. Clean APIs and stability, to me, are worth far more than being quick to adopt the latest trend. Otherwise we get competing pet standards again, "made for firefox / chrome" buttons, without significant developer adoption. Libraries and shimming aren't inherently bad, single line libraries on NPM are.

Re: Always Review Your Dependencies, AGPL Edition

#230

Post by RhysU » Wed, Jan 08, 2020, 10:27 AM UTC

ncmncm wrote: post #194

marcus_holmes wrote: post #176

Earlier quoted context omitted.

hmm, I always assumed it's a single "heeby-jeeby" and therefore multiple "heeby-jeebies", because that's how English mostly does singular/plural. But the repetition in "heebie-jeebies" looks more appealing. Even if grammatically unlikely. I'm confused now. Is "heebie-jeebies" intrinsically plural (like "sheep"), and therefore the pluralisation doesn't matter? Is there even such a thing as a single "heeby-jeeby"?

I can confidently state that I have never sighted a lone heeby-jeeby in the wild. Heebie-jeebies are best thought of as an affliction, like hives or bedbugs, characterized by shuddering and head-ducking. My guess is it started as a euphemism for hebephrenia, an obsolete affliction associated with youthful anxiety.

Seconded. Heebie-jeebies are uncountable.