873b8c90-7233-4e19-b044-a2096091c0af

[giscus[bot]]

873b8c90-7233-4e19-b044-a2096091c0af

Learn how to choose safe, reliable, and well-maintained dependencies. Reduce security risks, avoid abandoned libraries, and protect your application from supply-chain attacks by following a proven checklist for evaluating third-party packages.

https://www.ssw.com.au/rules/choose-dependencies-correctly/

[sam-s-maher]

Think back to a time when a dependency caused an issue (security, bugs, upgrades, etc.). What did you learn from that experience?

To update regularly! I've learned that the later you leave it to update your packages, the more arduous the process will be to get back up to date. This is especially painful when you're doing these updates in response to a recent global security issue panic.

[designbyalex]

As a UX designer, I'm stoked that AI is letting me touch more code. However, this rule hits home. When you’re vibe coding, it’s tempting to grab whatever library feels cool in the moment (or just let AI do its thing). The real flex is choosing tools that keep the product stable, scalable and easy for the whole team to work with. That’s how design and engineering stay in sync. 💪

[danielmackay]

.NET has built in vulnerability tracking and this will often cause build warnings.

My preferred way to document decisions on new packages is via ADRs

[Username-must-be-unique]

yea i am surprised that there is no link to the rules in the "documenting your decision": https://www.ssw.com.au/rules/architectural-decision-records/

[kulesy]

We had a package that had conflicting CSS classes. We analyzed whether the package was necessary and determined that we could build the components needed from scratch.

I learned that sometimes dependencies can make a rod for your own back; if you lean on them too much, you become locked into the functionality. You can also drown yourself in tech debt and time if you try to create functionality yourself. It's about weighing the time and cost of whether a package will provide a benefit over just doing it yourself.

[Lewkans]

Think back to a time when a dependency caused an issue (security, bugs, upgrades, etc.). What did you learn from that experience?

For major version upgrades, it's a good idea to view their upgrade guides (if they have one), as they list out all the changes and also how to change them so that you keep the same functionality. E.g. https://tailwindcss.com/docs/upgrade-guide. Better yet, they might even have a script that fixes most if not all issue when upgrading

[vladislav-kir]

Previously, when updating the project, I identified that some dependencies were no longer compatible, because one of them was not updated in 2 years.

When checking what the dependency was for, I realized that I could just as easily built a feature myself without relying on the package.

The lesson - if feature is simple enough to do without adding a dependency - do it yourself.

[steven0x51]

when I did a code review I noticed a new package was added, so I wen to look at the package notice it was lasted edited 4 years ago.

What I learned was when during code review we should also check what dependency been added in

[stephanfakossw]

Great reminder about choosing dependencies carefully

[edkranz]

Documenting dependency decisions is very important, and could be a subsection of your architecture decision record

[RobJT-wq]

The only way to fully trust a dependency is to rewrite it.

[wicksipedia]

Before pulling in another dependency, consider whether you can just own the few lines you need. It helps reduce supply‑chain exposure and avoids recreating the scenario from https://xkcd.com/2347/ where the whole world runs on one unloved, two‑line script.

[bahjatalaadelssw]

I'm keen to get one of those ubikeys for 2FA.

[isaaclombardssw]

Keeping informed is paramount, so you can respond quickly.

Using standard tools such as npm audit is also valuable to try and find vulnerabilities.

[amankumarrr]

Wow, this is a very informative video and an impressive malicious technique. It also makes me even more aware of the need to be careful when selecting an npm package.

[ZenoWang1999]

Most of the time, we don’t update dependencies lightly unless there is a known vulnerability. The relationships among dependencies are always complex, and an unconsidered update may cause them to become incompatible.

[thom-wang]

My team had a "left-pad incident" several years ago, and we updated the whole package dependencies very soon in an urgent overtime. And then we introduced a regular npm audit session every 1 or 2 sprints.

[babakamyljanovssw]

If a feature is easy to implement, then write it by ourselves would be go option. Otherwise choosing the right dependency as per the points mentioned in the Rule will help to decide better option. I think there should be workflow for the project which runs every 1-2 weeks to check if there are vulnerability packages.

[miichaelsmedley]

even Vibe coders... (me) need to worry about this :/

[TobyChurches]

Great rule and super thorough!! When adding new dependencies to your code it is VERY important to make sure that you are picking the correct one! If the dependency is not being maintained you might just be adding unwanted tech dept - "You are only as strong as your weakest link"

[SamBWagner]

Really excellent Rule! Great work!

[jeoffreyfischer]

Scary! I didn't know that NPM packages could inject malicious scripts using GitHub actions.. That's smart and shows how we should always be careful when using external packages

[Ben0189]

When a feature is simple, it is better to implement it in-house rather than adding a new dependency. AI-assisted development significantly reduces implementation time, so making custom solutions could be easier than what we thought nowadays