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?

  • @lysdexic@programming.dev
    link
    fedilink
    English
    51 year ago

    Something in the dependency tree will yell at you that it is deprecated or discontinued.

    Only if you didn’t pinned the dependencies you actually consume, and expect that all your dependencies magically comply with semver.

    Blindly replacing dependency versions never worked, at least reliably. If you do not put in the work to ensure things work, more often than not you’ll be surprised by them not working.

    • AggressivelyPassive
      link
      fedilink
      51 year ago

      Then you’ll end up with tons of vulnerabilities within days. That can’t be the solution either.

      • @lysdexic@programming.dev
        link
        fedilink
        English
        41 year ago

        Then you’ll end up with tons of vulnerabilities within days.

        You only end up with vulnerabilities if you refuse to update your dependencies. Updating a dependency is something you need to do yourself, along with running build validation tests after a successful update. Just because npm can download newer packages that does not mean those packages are good.

        • AggressivelyPassive
          link
          fedilink
          41 year ago

          …which is the opposite of the comment above.

          So, you still have to go through all the dependencies, vulnerabilities and incompatibilities. Yes, you can now kind of control the timing, but it’s still unacceptable in my opinion, that you have to spend so much time just to not be an active danger to everyone.

          NPM is completely alone in that regard. Maven, Pypi, etc. don’t have these problems.

          • @lysdexic@programming.dev
            link
            fedilink
            English
            11 year ago

            So, you still have to go through all the dependencies, vulnerabilities and incompatibilities.

            That’s the point. There is no free lunch. Yet, you can live with stable, pinned versions and only upgrade the ones you really need to, and that means exercise your personal criteria instead of mindlessly upgrade everything just because there was a bump in a version number somewhere in an upstream dependency.

            Yes, you can now kind of control the timing,

            Timing, extent, scope, and impact. That’s the point.

            but it’s still unacceptable in my opinion, that you have to spend so much time just to not be an active danger to everyone.

            You only spend the time you decide to spend. There are already vulnerability scanners that pinpoint exactly which versions need to be updated, and do that automatically for you. Mindlessly opening the floodgate to each and every change is by definition idiocy and a liability.

    • @planish@sh.itjust.worksOP
      link
      fedilink
      31 year ago

      Often it seems that people will make patch releases that add a “feature” of complaining at install time that that major release/minor release/entire package is bad now and should be replaced with something else. It still works, but it annoys everyone who transitively depends on it forevermore.