3 ms·

I am (usually) not a JS dev, but we have quality standards which are, to some extend, regulated in my business (banking/payments), so to use this, I would not o

I am (usually) not a JS dev, but we have quality standards which are, to some extend, regulated in my business (banking/payments), so to use this, I would not only want to, but to some extend need to understand all (ok, maybe not all, but at least the ones that seem to not be maintained very well or the ones that come from lone devs who might find another hobby and just quit maintaining) these 1568 dependencies and audit them for security every update. I would need to make sure they are maintained and if not decide if we will maintain them (if we are on a certain version of a NuGet package (we use .NET Core mostly) and the maintainer quits but somewhere in our stacks something depends on it, we have to make this decision, but we or the packages we use simply do not have that many dependencies). I do not want to dismiss other companies by saying 'apparently they don't care' but in the React/Node (JS) space in general, that feeling does creep up quite often when I read HN.

hombre_fatal 8y ago
Though this submission is talking about development dependencies rather than runtime dependencies. For example, the scaffolding it generates builds a Javascript app that runs in the user's browser. Still a potential problem, since each transitive dependency even gets to run arbitrary code during install on the developer's machine, but a different one.
- tluyben2 8y ago
  Point taken, but then we get into the 'omg how is this development package installed on the prod machines?' ' Because it is convenient for finding issues'. I am sorry to say I know disturbingly many devs that run dev on prod because they can just continue devving on prod. That's not restricted to Node but I see it with RoR and .NET Core as well. That would not pass muster at all for me but I see it quite often and interestingly not in startups but bigger companies on departmental level (no code reviews there anyway...).
- marcus_holmes 8y ago
  The problem here is that any code run during development could generate code that ends up in production. Even if the dependency isn't used in production, there is a "compile step" (though it's technically transpiled) during which all sorts of mayhem could ensue.
  - hombre_fatal 8y ago
    Absolutely. It's like a static site generator having a bunch of dependencies. I just wanted to refine the distinction, though it doesn't really change much. But you can at least be more prudent here than you could with 1,600 production runtime dependencies, like doing your development in an isolated environment on your own machine.
nicoburns 8y ago
Presumably you are not the target audience for something like this, which is a batteries-included getting started package. You could for example use React with TypeScript and have far, far fewer dependencies...
arenaninja 8y ago
I too work in this regulated business, and don't think your argument holds unless you don't inventory your dependencies and regularly scan code (source code and dependencies) for vulnerabilities

hombre_fatal 8y ago

Though this submission is talking about development dependencies rather than runtime dependencies. For example, the scaffolding it generates builds a Javascript app that runs in the user's browser. Still a potential problem, since each transitive dependency even gets to run arbitrary code during install on the developer's machine, but a different one.

tluyben2 8y ago
Point taken, but then we get into the 'omg how is this development package installed on the prod machines?' ' Because it is convenient for finding issues'. I am sorry to say I know disturbingly many devs that run dev on prod because they can just continue devving on prod. That's not restricted to Node but I see it with RoR and .NET Core as well. That would not pass muster at all for me but I see it quite often and interestingly not in startups but bigger companies on departmental level (no code reviews there anyway...).
marcus_holmes 8y ago
The problem here is that any code run during development could generate code that ends up in production. Even if the dependency isn't used in production, there is a "compile step" (though it's technically transpiled) during which all sorts of mayhem could ensue.
- hombre_fatal 8y ago
  Absolutely. It's like a static site generator having a bunch of dependencies. I just wanted to refine the distinction, though it doesn't really change much. But you can at least be more prudent here than you could with 1,600 production runtime dependencies, like doing your development in an isolated environment on your own machine.

nicoburns 8y ago

Presumably you are not the target audience for something like this, which is a batteries-included getting started package. You could for example use React with TypeScript and have far, far fewer dependencies...

arenaninja 8y ago

I too work in this regulated business, and don't think your argument holds unless you don't inventory your dependencies and regularly scan code (source code and dependencies) for vulnerabilities