Steps to reproduce:

  1. Start a Node project that uses at least five direct dependencies.
  2. Leave it alone for three months.
  3. Come back and try to install it.

Something in the dependency tree will yell at you that it is deprecated or discontinued. That thing will not be one of your direct dependencies.

NPM will tell you that you have at least one security vulnerability. At least one of the vulnerabilities will be impossible to trigger in your particular application. At least one of the vulnerabilities will not be able to be fixed by updating the versions of your dependencies.

(I am sure I exaggerate, but not by much!)

Why is it like this? How many hours per week does this running-to-stay-in-place cost the average Node project? How many hours per week of developer time is the minimum viable Node project actually supposed to have available?

  • @[email protected]English
    34•1 year ago

    So many reasons. JS has a small standard library, a history of competing standards for things like asynchrony and modules, there are tons of different implementations against tons of different specs, running in tons of different environments (whose constraints and opportunities are also changing all the time), it tends to be the first language to receive an SDK for many services, packages tend to be almost-excessively granular because optimizing for size can be so important on certain platforms (tree-shaking and minification works, but takes time), there are many add-on languages like JSX and TS, there are tons of bundlers and transpilers which each have their own quirks… and also due to its unique position as the lingua franca of client-side web, it tends to be the primary battleground for researchers, tech firms, VC, FOSS, malicious users, and everything else.

    To stay alive in an ecosystem like that, any project must become a “ship of theseus” kind of deal.

    You may be interested in yarn’s “zero-installs” option: https://yarnpkg.com/features/zero-installs