5 ms·

> Solve this and you'll solve the biggest complaints people have about JS. Or, perhaps, we can just tell people that their complaints are nonsensical when most

> Solve this and you'll solve the biggest complaints people have about JS. Or, perhaps, we can just tell people that their complaints are nonsensical when most of the deps are not actually packaged into the final app or being used at runtime, instead of contorting ourselves to fit their silly worldview. I'm not losing any money over this. Why should I care?

ucarion 6y ago
Not saying this is automatically a problem, but you will lose money over this. When a build dependency is unavailable or broken, you cannot create production artifacts. You'll lose money over this because broken builds lead to incidents, longer time-to-recovery during incidents, and slower development. All of these cost money. Your exposure to defects in your build dependencies will depend on a lot of factors, but the exposure will always be there.
- tiglionabbit 6y ago
  Then cache the dependencies you're using.
- striking 6y ago
  Deps aren't unavailable or broken if I cache and pin them, and I do, because not having done so would have cost me a lot of time and money a long time ago.
ratww 6y ago
People did lose money when left-pad was not available. Sure, it was only a day and the whole class of issue solved now, but there are other modes of attack. And dev dependency bloat might be nonsensical to you but it's not nonsensical to me. Different people have different priorities, that's it. So yeah, maybe you can afford not to care, but that doesn't mean you should give us that can't a hard time about it :)
- striking 6y ago
  I'm pretty sure then that if you actually knew what was inside your C compiler, you might lose your mind. There is something akin to an entire LISP inside gcc. And it uses its own host of deps, which themselves have deps... https://packages.gentoo.org/packages/sys-devel/gcc/dependencies https://packages.gentoo.org/packages/sys-devel/gcc/dependenc.... It's not like these compilers are large for no reason, there's definitely code in them. What do you consider the preprocessor if not bloat? CMake or ninja or whatever Google's build system is, is that bloat? Maybe you just haven't seen a fun enough pipeline. But the web is sufficiently complex that you need a sufficiently complex set of developer tools to build for it in an optimal way. You can try and skip steps there but you'll likely just end up reinventing what others have built. If you know the leftpad class or issues is gone, why bring it up? Why not just start with the "other modes of attack"? Why do your priorities, whatever they are, matter? I'm not the one giving others a hard time here, the people who maintain that it is fun and trendy to hate on a technology they think is "bloated" (whatever that means) are giving me the hard time.
marcus_holmes 6y ago
Is there anything stopping a dev dependency from injecting malicious code into your app?
- striking 6y ago
  Yeah, it's called pinning. When you use yarn or npm, they generate a lock file that pins the exact state of your downloaded set of node modules, so you can't accidentally download a different set of artifacts that might be poisoned. As for "but what if they hide it?" that's just a problem with compilers. A very "Reflections on Trusting Trust" sort of thing. I'm usually a few versions behind, so if anything like that were to exist it would have been caught by someone else.
  - johnisgood 6y ago
    For people who may want to read more about the " Reflections on Trusting Trust": https://www.win.tue.nl/~aeb/linux/hh/thompson/trust.html https://www.win.tue.nl/~aeb/linux/hh/thompson/trust.html and https://wiki.c2.com/?TheKenThompsonHack https://wiki.c2.com/?TheKenThompsonHack.

ucarion 6y ago

Not saying this is automatically a problem, but you will lose money over this. When a build dependency is unavailable or broken, you cannot create production artifacts. You'll lose money over this because broken builds lead to incidents, longer time-to-recovery during incidents, and slower development. All of these cost money. Your exposure to defects in your build dependencies will depend on a lot of factors, but the exposure will always be there.

tiglionabbit 6y ago
Then cache the dependencies you're using.
striking 6y ago
Deps aren't unavailable or broken if I cache and pin them, and I do, because not having done so would have cost me a lot of time and money a long time ago.

ratww 6y ago

People did lose money when left-pad was not available. Sure, it was only a day and the whole class of issue solved now, but there are other modes of attack. And dev dependency bloat might be nonsensical to you but it's not nonsensical to me. Different people have different priorities, that's it. So yeah, maybe you can afford not to care, but that doesn't mean you should give us that can't a hard time about it :)

striking 6y ago
I'm pretty sure then that if you actually knew what was inside your C compiler, you might lose your mind. There is something akin to an entire LISP inside gcc. And it uses its own host of deps, which themselves have deps... https://packages.gentoo.org/packages/sys-devel/gcc/dependencies https://packages.gentoo.org/packages/sys-devel/gcc/dependenc.... It's not like these compilers are large for no reason, there's definitely code in them. What do you consider the preprocessor if not bloat? CMake or ninja or whatever Google's build system is, is that bloat? Maybe you just haven't seen a fun enough pipeline. But the web is sufficiently complex that you need a sufficiently complex set of developer tools to build for it in an optimal way. You can try and skip steps there but you'll likely just end up reinventing what others have built. If you know the leftpad class or issues is gone, why bring it up? Why not just start with the "other modes of attack"? Why do your priorities, whatever they are, matter? I'm not the one giving others a hard time here, the people who maintain that it is fun and trendy to hate on a technology they think is "bloated" (whatever that means) are giving me the hard time.

marcus_holmes 6y ago

Is there anything stopping a dev dependency from injecting malicious code into your app?

striking 6y ago
Yeah, it's called pinning. When you use yarn or npm, they generate a lock file that pins the exact state of your downloaded set of node modules, so you can't accidentally download a different set of artifacts that might be poisoned. As for "but what if they hide it?" that's just a problem with compilers. A very "Reflections on Trusting Trust" sort of thing. I'm usually a few versions behind, so if anything like that were to exist it would have been caught by someone else.
- johnisgood 6y ago
  For people who may want to read more about the " Reflections on Trusting Trust": https://www.win.tue.nl/~aeb/linux/hh/thompson/trust.html https://www.win.tue.nl/~aeb/linux/hh/thompson/trust.html and https://wiki.c2.com/?TheKenThompsonHack https://wiki.c2.com/?TheKenThompsonHack.