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?

  • @AA5B@lemmy.world
    21•11 months ago

    They’re all that way: it’s just that Node is automatic enough to notice more easily, plus had an insane number of small dependencies

    We started doing vulnerability scans on every build, which sounds like a good idea. However, now I know: Java is exactly the same. We need to constantly update but all too often there is no update available yet

    • body_by_make
      3•11 months ago

      C# is also exactly the same, you just don’t get yelled at when things are out of date and you only see that if you go to manually install packages

      • Kogasa
        3•11 months ago

        In C# you can automatically generate (or manually write) binding redirects that let you say “anything using versions between x.y.0 and x.y.9 should use x.y.9”, which helps a lot with transitive dependencies. However, doing this manually is hard, and you can’t really rely on semver to be done “correctly.” This leads to subtle bugs. Occasionally not so subtle, but hard to diagnose.