2 posts tagged with "yarn"

I've been fixing quite a few package CVEs in Node.js projects at work lately, so I wanted to write down the decision process while it's still fresh. The first time I saw CVEs, Fixed Version fields, and long node_modules paths in a scan report, all I knew was “some packages need upgrading.” I had no idea how to go about it. For the first few fixes, I kept looking things up and asking AI for help. After working through several dependency setups, I started to see the pattern: fixing Node.js package vulnerabilities means reading the dependency tree, checking version ranges, and choosing the smallest safe change. The options differ considerably depending on whether the vulnerable package is a direct dependency, a transitive dependency, pinned to an exact version, or no longer maintained. I'll walk through the situations I've encountered and worked through, so you can see the reasoning behind each decision.

Some background:
I've recently been building an npm package for our internal frontend team. One challenge was that I'd never developed an npm package before, so I was starting from scratch with the development environment, bundling, publishing, and maintenance. The company also didn't want to open-source the package or pay for npm Orgs' private package feature. Alongside learning how to build the package, I had to find a free way to host a private npm library that would work for us.