4 ms·

But this doesn't address the author's point that each module, each dependency is an additional point of failure.

lewisl9029 11y ago
There are definitely trade-offs involved when making decisions to inline vs import. Strictly speaking, you're definitely right. Each dependency is an additional point of failure, but so is each additional line of code you inline. The benefits of these small modules is that they're very thoroughly tested by the entire community. I'd say for most cases, they will be much more robust than any solution an individual developer can spontaneously whip up. Of course, these modules don't exist in a vacuum, and infrastructure failures such as this one do pose another point of failure you wouldn't have with inlining code, but I think in this particular case it had more to do with the failure of npm to adhere to package management best practices to not include an unpublish feature.
- coldtea 11y ago
  >There are definitely trade-offs involved when making decisions to inline vs import. If someone can't make the right trade-off regarding "should I import a module called "isArray" or "is-positive-integer", then they should not be programming...
  - lmm 11y ago
    Yep. Everyone mocking NPM and the javascript community for this ought to retire, they clearly don't understand how to program in this day and age. Or is that not what you meant?
  - robmcm 11y ago
    I think a lot of the confusion here is that in most languages "isArray" or "is-positive-integer" are simple functions of simply build into the language. Dynamic typing and diversity of devices and virtual machines mean the ability to simple tell if something is an Array could be multiple lines of code that could take a considerable amount of time to test. Delegating this to the community is arguably the only sane choice, however strange that may be to someone come from another environment.

There are definitely trade-offs involved when making decisions to inline vs import. Strictly speaking, you're definitely right. Each dependency is an additional point of failure, but so is each additional line of code you inline. The benefits of these small modules is that they're very thoroughly tested by the entire community. I'd say for most cases, they will be much more robust than any solution an individual developer can spontaneously whip up. Of course, these modules don't exist in a vacuum, and infrastructure failures such as this one do pose another point of failure you wouldn't have with inlining code, but I think in this particular case it had more to do with the failure of npm to adhere to package management best practices to not include an unpublish feature.

coldtea 11y ago
>There are definitely trade-offs involved when making decisions to inline vs import. If someone can't make the right trade-off regarding "should I import a module called "isArray" or "is-positive-integer", then they should not be programming...
- lmm 11y ago
  Yep. Everyone mocking NPM and the javascript community for this ought to retire, they clearly don't understand how to program in this day and age. Or is that not what you meant?
- robmcm 11y ago
  I think a lot of the confusion here is that in most languages "isArray" or "is-positive-integer" are simple functions of simply build into the language. Dynamic typing and diversity of devices and virtual machines mean the ability to simple tell if something is an Array could be multiple lines of code that could take a considerable amount of time to test. Delegating this to the community is arguably the only sane choice, however strange that may be to someone come from another environment.