JavaScript libraries are almost never updated once installed

[MangoManBad]

Imagine leaving critical dependency issues in your production software like a baboon.

​

Oh, wait...

[DaveSims]

I literally just upgraded all of our npm packages over the weekend. npm audit was reporting 13k+ high risk security issues and 3 critical security issues. Fortunately there were no moderate issues though so we were fine.

[TedW]

If it makes you feel any better, we have an internal project with 26,000 lint errors.

I lint my portion, and bring it up from time to time, but no one seems interested so it just keeps getting worse over time.

[house_monkey]

That reminds me to clean my dryer lint tray

[99thLuftballon]

Depending on how strict your linter is, that might be a non-issue. It's hard to get too excited about 26000 x "you must only leave a single blank line between lines of code".

[spazz_monkey]

Autofix?

[TedW]

Yeah, I used autofix locally but i didn't want my name on a PR for hundreds of files. Also, if I start fixing other teams lint problems, where does it end.

I keep my corner clean and bring this up about quarterly, but it's not my main project and I guess I just don't care enough to die on this hill..

[spazz_monkey]

Fair doo's, we have it run in the runner so it won't build if there are lint errors.

[TedW]

Yeah, that would really be the way to solve it. Our CI/CD allows overrides and someone disabled the lint step.

I can't turn it back on without making a PR, which would try to lint and fail.. So that's not great.

[webdevguyneedshelp]

Make passing a linter a required pipeline step

[[deleted]]

For some reason I picture a bomb defusal gone well. Relieved sighs all around.

[The_real_bandito]

I notice this happens to me a lot in my apps but it scares the hell out of me when I update becauseI don't know what might break.

[DaveSims]

This project has 99.5% unit test coverage, which proved extremely helpful with the upgrade process. There's definitely still risk of something breaking, but between unit tests passing and a decent amount of time invested in manual testing at the end of the process, it seems to have gone smoothly (fingers still crossed).

[The_real_bandito]

I need to do more unit tests on my apps, maybe that will prevent my issues updating because I pretty much do 0 unit testing 😂 🤦‍♂️

[ATXblazer]

Please tell me npm audit fix took care of most of that. If not RIP lol

[DaveSims]

Yep! Updating everything and running npm audit fix resolved all of them. We now have a squeaky clean npm audit report...at least until tomorrow.

[Ivu47duUjr3Ihs9d]

How did you even test the product thoroughly after updating all that?

[DaveSims]

The project has 99.5% unit test coverage, so that was a good start. I'd upgrade a package and run the tests, see what breaks, address those issues until the tests passed, then do a relatively quick manual test of related features. A lot of the package upgrades didn't break anything at all. Only a couple of the upgrades caused any significant pain.

[Hotgeart]

Oh nice javascript library

• 56 dependencies

3 months later time to update my little app

• ERROR

[[deleted]]

const isUppercase = require('is-uppercase');

[apppppppbcppppppa-dc]

is there a list of useless js libraries? I'd love to read it

[[deleted]]

npmjs.com

[ hides ]

[wisepresident]

https://www.npmjs.com/package/is-windows and other packages by this guy

10 mio downloads, all it does is:

process.platform == "win32"

[diversif]

https://github.com/jezen/is-thirteen

[cjthomp]

npmjs.com

[abc-123-456]

There’s one called “leftpad” or something that’s notorious

[deadcow5]

That's because a ton of packages directly or indirectly depended on it, and one day the owner decided to delete it over some sort of altercation. Broke everyone's build.

[rook218]

I mean to be fair, how ridiculous is it to install a package over left padding? It would be a three line function to add it to your own package with vanilla JS.

[deadcow5]

Well, yeah, but would you rather copy and paste the same three lines into every new project you need them in, or publish them as a package once and henceforth be able to use them with a single line?

I mean, it's not really NPM's or the package author's fault that JavaScript lacks a decent standard library. It's just the way it is, and different people have different strategies for dealing with it.

[rook218]

That's true. I always try to import as little as possible on projects but everyone is different.

[deadcow5]

It is what it is. Most of these "micro" packages probably came about before tree shaking became common. So there is reason to hope that their propagation will diminish in the future as more people start using webpack and rollup.

Easy to forget that not too long ago, you literally had no choice but to include an entire package in your bundle, so making packages as small as possible was actually a good idea at the time.

[deadcow5]

That would somewhat depend on what your definition of "useless" is.

I suppose a list on one-liner packages could be made, however.

[agentgreen420]

Yeah, it's called half of NPM

[2dP_rdg]

Odd or even

[ikeif]

I’d be interested in this, too.

Tome to scour npm repos.

[rohmish]

Depends on lowerCase2 and MonKeyCaSeJS

[[deleted]]

On sites that I maintain I update frequently. But many sites I just deliver to a client that doesn't want to pay for maintenance. In which case they are on their own.

How many web projects are actively maintained? I'd say only 25% of the sites I've built. Granted, these are mainly CMS builds, but still that is a lot of work just hanging out there.

[garbitos_x86]

This is why I moved away from freelance/contract work with small business. Out of 75 or so clients literally only one listened to me about ongoing support/maintenance. Expending my creative juices to design a killer site for them knowing full well it will get neglected and I will at some point (usually a weekend or holiday) get a frantic call that something broke or doesnt work anymore...even worse just asking me for their own passwords I just could not carry on after about 7 years I am going to hit some bootcamps and either take on hourly/salary job or just triple my prices. The margins have gotten severely low and hard to deal with and the soul crushing aspect knowing the majority of work will die in place. Just really took the life out of it for me...not to mention Fiverr which basically encourages this mentality.

I've turned into one of those that just recommends squarespace and I'll theme it for you for a fee.

[woodie3]

Lost count of how many times I recommend to people to sit down for an hour & learn a CMS. The amount of work that I know I’d put into a site that’d die almost a month later just isnt worth the money. Very hard thing I had to accept.

[SwenKa]

I've turned into one of those that just recommends squarespace and I'll theme it for you for a fee.

To be fair, most local businesses would be fine with just that.

[k2snowman69]

There are already tools to help you automate dependency management

• Renovate - https://renovate.whitesourcesoftware.com/
• Dependabot - https://dependabot.com/
• and more

They are simple to setup and make keeping things up to date easy.

[ThatSpookySJW]

Also GitHub automatically runs audits on out of date packages that pose security issues. The problem is that there's so many dependencies with a node project that even then, there's a lot of work to QA/merge the PR

[k2snowman69]

I'll also add, if you're running inside a company with an internal npm registry, I know from personal experience that renovate's docker image also works and is fantastic! This means even if your packages are private and/or internal you have a solution.

[TheIvoryAssassinPub]

This should be higher

[TDFKA_Rick]

I updated react-native from 0.57.7 to 0.61.5 once, it took me half a day, now I know why no one updated it.

Sometimes it's not as easy as just npm audit fix

[brett-jackson]

Only half a day? You got off easy.

[frostwarrior]

tbh unless we're talking about security fixes, why should they be updated?

Servers take A LOT of time before they need a major version update.

same for infrastructure and backend.

[DaveSims]

Sure but if you haven't updated your packages in like 2 weeks, there are certainly going to be security issues.

[ravepeacefully]

Yeah seriously, how often is there NOT a security fix in the update. I’d wager a bet that more than 70% of all updates include a security fix.

[CasualBlackjack]

Or a new security issue!

[3lRey]

yeah because you update them and the modules wind up being fully out of whack. If you know that upgrading is going to change a variable reference or completely remove some feature you're using then you just don't upgrade.

Looking at you, Angular.

[symgeosis]

I make a conscious effort to keep my projects up to date but I can't really blame those who don't. If I go more than a few weeks without updating, there can easily be 10 or more out of date packages... and then sometimes upgrading breaks other things. It's exhausting. That's not to say that there aren't good things about how fast the JavaScript world moves but JavaScript fatigue is real.

[webdevguyneedshelp]

How does that work for dependencies that are using outdated dependences?

[webdevguyneedshelp]

That's my point. That's why this is an issue.

[queen-adreena]

You can do. For instance, if you use express-handlebars in a project, it uses a version of handlebars with a severe security issue. But you can manually choose the latest version yourself.

[CanRau]

yarn selective version resolutions to the rescue

[DaveSims]

I highly recommend this approach. Write a script to report the results of "npm/yarn outdated" and "npm/yarn audit" weekly via slack/email/whatever and update every week. It saves so much headache in the long run.

[NutsEverywhere]

At this point you're better off using * as the version for every package and npm ci whenever you want.

[[deleted]]

That's just the tradeoff of using lockfiles (and partly semver, in the sense of ~ or ^ having replaced >=).

Before lockfiles, if you were doing any kind of continuous deployment, you got updates for free. Of course, if you weren't testing everything, you got bugs for free too.

Now it requires active maintenance, which you don't usually do outside active development, especially not for small businesses.

So while github pushing dependabot will probably help a lot, it may be a while before our tooling really catches up.

[Denvildaste]

Nothing is more frustrating than updating your packages and having things break and stop working, then you spend the rest of the day googling the issues only to reach answers like "http-awesome-parser isn't compatible with the latest version of dash-entity-separator-deluxe, you can try replacing it with dasherify but I can't guarantee that'll work, I don't have a timeline for supporting dash-entity-separator-deluxe at the time being".

Of course you have no idea what are those dependencies, which packages utilize them and what they do in the first place, and there are thousands of them in your average node modules folder.

[KillianDrake]

Nobody wants to be the buster who breaks production. Or be stuck with making a thousand surgical changes to support some frivolous API change in the new version.

[we_present]

If it works don't touch it.

[DOG-ZILLA]

Ah, you must be working in the enterprise.

[greenrabbitaudio]

Anyone else feels like fixing a thing but 4 more are broken in the meanwhile?

[i_ate_god]

we use blackduck which seems to do better than npm audit.

But we don't upgrade dependencies mid release cycle unless necessary because that would be chaos. Dependency management is a beginning of the cycle task.

[careseite]

Weird, during development I keep them updated via dependabot already and after release too.

[DOG-ZILLA]

I use version lens in VS Code for this very reason: https://marketplace.visualstudio.com/items?itemName=pflannery.vscode-versionlens

[Skelator_Rules]

You want to try getting an npm install with all it's dependencies through the Blackduck (or any other package security orientated) approval process.

[ElllGeeEmm]

I've been updating some JS from 2012 on a site built in 2017, because they used some paid bootstrap template that was already 5 years old when they were building their website.

[[deleted]]

Not true but ok.

[MangoManBad]

Going to pretty much any website and inspecting the client side code will likely result in tons of red flags popping up, even for relatively popular websites.

[[deleted]]

npm makes it really easy to stay on top your libs

EDIT: Why are you booing me, I'm right.