8 ms·

similarly, I refuse to use JS libs that have ridiculous dependency trees (most annoyingly, including Webpack, which means my Vue setup is more interesting than

similarly, I refuse to use JS libs that have ridiculous dependency trees (most annoyingly, including Webpack, which means my Vue setup is more interesting than it needs to be). I was explaining why to a friend, and it appears that no-one takes this threat seriously, not even in secure/financial apps. Like you, I wonder if I'm missing something obvious. Why does the npm dependency trust nightmare give me the screaming heeby-jeebies but everyone else thinks it's all perfectly fine?

ncmncm 7y ago
It's not just you. Screaming heebie-jeebies is exactly the correct response. People who don't worry about it tell themselves that nothing that matters very much is coded in javascript, obvious exceptions notwithstanding. Maybe the only practical way left to avoid it is to avoid javascript for things that matter, and to avoid products constructed with javascript for uses that matter. This might be an unpopular observation, but that does not make it wrong. It is possible that WASM can fix much of this, at the cost of exposing ourselves to what might be extreme risks inherent in WASM itself. And of course, to whatever dependencies are brought in for the language we compile to WASM.
- galangalalgol 7y ago
  Indeed, rust is a likely wasm choice and it is working on an npm nightmare of its own with crates.io. A blessed crates pack is sorely needed to fill out the intentionally thin stdlib in cases you can't afford a dependency tree 20 layers deep for all the reasons mentione on this thread.
  - steveklabnik 7y ago
    Several people have tried the "blessed crates pack" over the years, but they never gained traction, so people stopped working on them.
  - vmchale 7y ago
    It's unfortunate that Rust is so tied to cargo, and unfortunate that cargo insists on allowing multiple versions of a dependency. If you point out that cargo is poorly designed everyone just yells and you and says you don't understand.
    - damnyou 7y ago
      Only incompatible versions though — Rust dedups dependencies up to semver compatibility. I think that's the right balance. clap 3 is and should be treated as a totally different package from clap 2.
      - vmchale 7y ago
        It's not as bad as cabal back in the day. Nonetheless I have run into the diamond dependency problem in practice. Their solution is unprincipled and there's no way to turn off the default behavior.
        damnyou 7y ago
        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.
        vmchale 7y ago
        > 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.
        damnyou 7y ago
        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.
- marcus_holmes 7y ago
  Yeah, my back-end is in Go, so being able to write the front end in Go as a simple cross-compile is great, if it was that simple. We're a long way from it being that simple. There are "hello world" examples, but nothing close to a working GUI in Go-WASM yet. I'd love a clone of Vue in Go-WASM. Just saying, if anyone out there wants to give it a try ;)
- marcus_holmes 7y ago
  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"?
  - ncmncm 7y ago
    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.
    - RhysU 7y ago
      Seconded. Heebie-jeebies are uncountable.
      - marcus_holmes 7y ago
        I'll go with the consensus opinion, then. "Heebie-jeebies" it is :)
        ncmncm 7y ago
        The dictionaries credit a comic strip "Barney Google" with coining the expression. No saying whether that is really where the New Evil Empire got its name.
syshum 7y ago
Because even in 2020, even in " secure/financial apps" most programmers have security and lic legality as a secondary (or even forth level) concerns, they just want to "make something cool" They play lip service to it being secure, and/or license compliant
- jsjohnst 7y ago
  I would argue the reason developers don’t have concerns around licensing is partly due to lack of knowledge around the differences between licenses at a fundamental level and partly due to a “why should I care?” mentality at least at a subconscious level, if not higher. A got a taste of it yet again this past weekend when I commented here on HN about GPL and AGPL being licenses that corporations often have concerns with.
  - mr_toad 7y ago
    I find it’s the opposite - people with limited understanding of licensing (and IP law in general) often have the most concerns, and misapprehensions.
vmchale 7y ago
> it appears that no-one takes this threat seriously, not even in secure/financial apps. I think that's pretty standard for our industry, even outside the often comically lazy world of JS.
Lammy 7y ago
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.
- flanbiscuit 7y ago
  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 https://npm.anvaka.com/#/view/2d/webpack Parcel - https://npm.anvaka.com/#/view/2d/parcel https://npm.anvaka.com/#/view/2d/parcel Rollup - https://npm.anvaka.com/#/view/2d/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 or cli packages that you'll need to work with each of these but I also found the dependency tree of each of the added Rollup plugins to be less than the other 2. here's rollup-plugin-babel: https://npm.anvaka.com/#/view/2d/rollup-plugin-babel https://npm.anvaka.com/#/view/2d/rollup-plugin-babel
  - marcus_holmes 7y ago
    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...
  - Lammy 7y ago
    Rollup looks like it would fit my needs perfectly. Thank you!
tomlagier 7y ago
I don't think anyone thinks it's perfectly fine (well, maybe newer people in the industry). I just don't think anyone sees a viable alternative. By adopting any semblance of a modern front-end stack, you're going to be pulling in a huge dependency tree. So, your choices are: A) Don't do modern front-end development. This, despite being very popular with the HN crowd, is a challenging option. Losing the power of popular frameworks makes it difficult to recruit new developers, slows down developer velocity, and can cause tech debt to accrue more quickly. B) Validate every dependency. For a skilled security reviewer, this may be possible. For an average developer however, reviewing thousands of dependencies is unlikely to be a good use of time. There are some improvements, automated tools that can be run, but the unfortunate reality is that the NPM attack surface is massive and I don't know of any techniques for producing any truly reliable security assessment. C) Depend only on packages that you trust and trust them to validate their dependencies. Obviously, if this transitive trust breaks down at any layer then a vulnerability is introduced. In practice, I've only ever seen individuals and companies do C. I think if there was some tooling around B, that would be the best option. I see a lot of room for disruption here - if there was a way to assign trust to a dependency and then a package-manager level construct that would only allow trusted dependencies to be installed, that might work. I think the ship has sailed on A.

ncmncm 7y ago

It's not just you. Screaming heebie-jeebies is exactly the correct response. People who don't worry about it tell themselves that nothing that matters very much is coded in javascript, obvious exceptions notwithstanding. Maybe the only practical way left to avoid it is to avoid javascript for things that matter, and to avoid products constructed with javascript for uses that matter. This might be an unpopular observation, but that does not make it wrong. It is possible that WASM can fix much of this, at the cost of exposing ourselves to what might be extreme risks inherent in WASM itself. And of course, to whatever dependencies are brought in for the language we compile to WASM.

galangalalgol 7y ago
Indeed, rust is a likely wasm choice and it is working on an npm nightmare of its own with crates.io. A blessed crates pack is sorely needed to fill out the intentionally thin stdlib in cases you can't afford a dependency tree 20 layers deep for all the reasons mentione on this thread.
- steveklabnik 7y ago
  Several people have tried the "blessed crates pack" over the years, but they never gained traction, so people stopped working on them.
- vmchale 7y ago
  It's unfortunate that Rust is so tied to cargo, and unfortunate that cargo insists on allowing multiple versions of a dependency. If you point out that cargo is poorly designed everyone just yells and you and says you don't understand.
  - damnyou 7y ago
    Only incompatible versions though — Rust dedups dependencies up to semver compatibility. I think that's the right balance. clap 3 is and should be treated as a totally different package from clap 2.
    - vmchale 7y ago
      It's not as bad as cabal back in the day. Nonetheless I have run into the diamond dependency problem in practice. Their solution is unprincipled and there's no way to turn off the default behavior.
      - damnyou 7y ago
        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.
        vmchale 7y ago
        > 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.
        damnyou 7y ago
        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.
marcus_holmes 7y ago
Yeah, my back-end is in Go, so being able to write the front end in Go as a simple cross-compile is great, if it was that simple. We're a long way from it being that simple. There are "hello world" examples, but nothing close to a working GUI in Go-WASM yet. I'd love a clone of Vue in Go-WASM. Just saying, if anyone out there wants to give it a try ;)
marcus_holmes 7y ago
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"?
- ncmncm 7y ago
  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.
  - RhysU 7y ago
    Seconded. Heebie-jeebies are uncountable.
    - marcus_holmes 7y ago
      I'll go with the consensus opinion, then. "Heebie-jeebies" it is :)
      - ncmncm 7y ago
        The dictionaries credit a comic strip "Barney Google" with coining the expression. No saying whether that is really where the New Evil Empire got its name.

syshum 7y ago

Because even in 2020, even in " secure/financial apps" most programmers have security and lic legality as a secondary (or even forth level) concerns, they just want to "make something cool" They play lip service to it being secure, and/or license compliant

jsjohnst 7y ago
I would argue the reason developers don’t have concerns around licensing is partly due to lack of knowledge around the differences between licenses at a fundamental level and partly due to a “why should I care?” mentality at least at a subconscious level, if not higher. A got a taste of it yet again this past weekend when I commented here on HN about GPL and AGPL being licenses that corporations often have concerns with.
- mr_toad 7y ago
  I find it’s the opposite - people with limited understanding of licensing (and IP law in general) often have the most concerns, and misapprehensions.

vmchale 7y ago

> it appears that no-one takes this threat seriously, not even in secure/financial apps. I think that's pretty standard for our industry, even outside the often comically lazy world of JS.

Lammy 7y ago

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.

flanbiscuit 7y ago
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 https://npm.anvaka.com/#/view/2d/webpack Parcel - https://npm.anvaka.com/#/view/2d/parcel https://npm.anvaka.com/#/view/2d/parcel Rollup - https://npm.anvaka.com/#/view/2d/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 or cli packages that you'll need to work with each of these but I also found the dependency tree of each of the added Rollup plugins to be less than the other 2. here's rollup-plugin-babel: https://npm.anvaka.com/#/view/2d/rollup-plugin-babel https://npm.anvaka.com/#/view/2d/rollup-plugin-babel
- marcus_holmes 7y ago
  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...
- Lammy 7y ago
  Rollup looks like it would fit my needs perfectly. Thank you!

tomlagier 7y ago

I don't think anyone thinks it's perfectly fine (well, maybe newer people in the industry). I just don't think anyone sees a viable alternative. By adopting any semblance of a modern front-end stack, you're going to be pulling in a huge dependency tree. So, your choices are: A) Don't do modern front-end development. This, despite being very popular with the HN crowd, is a challenging option. Losing the power of popular frameworks makes it difficult to recruit new developers, slows down developer velocity, and can cause tech debt to accrue more quickly. B) Validate every dependency. For a skilled security reviewer, this may be possible. For an average developer however, reviewing thousands of dependencies is unlikely to be a good use of time. There are some improvements, automated tools that can be run, but the unfortunate reality is that the NPM attack surface is massive and I don't know of any techniques for producing any truly reliable security assessment. C) Depend only on packages that you trust and trust them to validate their dependencies. Obviously, if this transitive trust breaks down at any layer then a vulnerability is introduced. In practice, I've only ever seen individuals and companies do C. I think if there was some tooling around B, that would be the best option. I see a lot of room for disruption here - if there was a way to assign trust to a dependency and then a package-manager level construct that would only allow trusted dependencies to be installed, that might work. I think the ship has sailed on A.