Picking on third-party deps

A colleague of mine from a couple of years ago is looking for work, and is blogging about the process of interviewing and about lessons learned from technical interview feedback. (In my opinion this level of critical self-evaluation would qualify him for at least an interview, were I in charge of looking for new software developers.)

He recently received this feedback on an exercise in building a POST handler for an API:

We liked that payloads were validated, but found the validation to be quite manual. It might have been nice to have used a 3rd party library, which can provide better error messages, as well as good TypeScript integration to couple to interfaces

I disagree with this feedback. My first instinct is never to try and install my way out of a design problem, because what I'm really doing is installing my way into three types of of technical debt:

1. Dependencies incur a network cost. Yup (270KB), Joi (558KB), and Zod (3.7MB (???)) all ship more data over the wire. It's bad enough if you're downloading and installing these on a single server on every CI run; god help you if you're shipping them to the client. Or god help your users, I don't know.
2. Dependencies incur a sustainability cost. As of writing, Zod has 740 versions. If you are installing Zod, I hope you are also setting aside a couple of hours each sprint to keep it up-to-date and compatible with all the other crud in your node_modules.
3. Dependencies incur an onboarding cost. I wonder whether this organisation, which is obviously hiring, has budgeted for the extra time to onboard not only to the org's codebase, but to the basket of third-party libraries that they encourage their software developers to install.

I'm picking on Zod, but I suspect that the developer agrees with me: Zod relies on precisely zero third-party (runtime) libraries.

Here's an alternative: just write your own request validator. Yes, it's a dependency — but this makes it your dependency. Want to upgrade it? Need to handle new formats for error messages? Tweak it & commit. Your validator will be bespoke to your use-case, and your new devs won't have to trawl through node_modules if they want to read the source. And if your source isn't 122K LoC they're more likely to, uh, do that.

Hell, you don't even have to write your own: you can get Claude to do it for you. Here's a prompt, on the house:

Please write up an extremely lightweight validation library for HTTP requests in <my-web-framework>. Ideally a single class/function that I can just pass the request to, and a config object indicating what values are required or acceptable

I'm willing to accept that there are valid use cases for Zod or Joi or Yup (although maybe not quite 39 million every week). But before you hit npm i or pip install or composer install or whatever, ask yourself: what do we need, and can we do it ourselves?

Further reading

• Boring Technology Club - how many times do I have to link to this talk
• Spoon theory - when you run npm i you lose a spoon