One of the least glamorous parts of working on a frontend platform team is keeping frontend dependencies up to date. This is made even more challenging by the fact that it usually takes many years before a company builds a team devoted to frontend infrastructure. By then, critical dependencies are woefully out of date and require risky migration paths, there are security vulnerabilities, and there is no process in place to stop the bleeding.

Over the past few years, I've been part of some processes that have worked well. This is my recommended approach.

Track metrics

You or your manager will need to make sure that leadership understands the value of keeping dependencies up to date. Once leadership understands the work, they'll want to know whether you're executing. The best way to show this is to track metrics.

Depending on your package manager, you can run a script to check which packages are outdated. In pnpm, for example, you can run pnpm outdated or npm outdated to retrieve this information. You can write a script to parse the results, and send that data to a tool like Honeycomb to track your progress over time.

Set up an on duty rotation

If you don't have one already, your team should create an on duty rotation so that this type of work is spread evenly across all team members. One engineer a week should be responsible for "keep the lights on (KTLO)" work. This includes tasks like answering slack messages, helping colleagues use the design system, resolving security vulnerabilities, and managing dependabot.

When I've been on frontend infrastructure teams without an on duty rotation, a lot of this KTLO work has fallen on one or two engineers. And generally this is not considered "promotable" work, even though I'd argue it is highly important. It's best to spread it fairly amongst team members.

Configure Dependabot

Dependabot is a tool that automatically opens pull requests in your repository when new versions of dependencies are published. You can follow the documentation to configure it in the appropriate way for your organization. Once you configure it, it will start to open prs immediately.

As you refine your process, you can change how many pull requests you would like it to open per week. It will then be the job of the on duty engineer to review the upgrade and decide whether to merge or close the pr.

Another great feature of dependabot is grouped upgrades. If you use a tool like storybook, you probably have all kinds of plugins that are associated with it. You want to make sure that you upgrade all of these dependencies at the same time so that you don't run into any kinds of cross-version issues.

Define a process for managing Dependabot

I've seen multiple organizations set up Dependabot without having any process for managing it. While some dependencies occasionally get merged, a frontend infrastructure team needs to ensure that it's improving its metrics and actively improving the developer experience of working on the frontend.

An example process

The on duty engineer should check open Dependabot prs daily. They should determine whether the upgrade is a major, minor, or patch upgrade.

Patch or minor upgrade

If it is a patch or minor upgrade, they should test and merge the change. Or if they aren't quite sure, they should tag the relevant team and give them 24 hours to review the change before merging.

Major upgrade

If it is a major upgrade, it needs to be slotted into the team's roadmap. The engineer should make a ticket, and should tag the team that should most likely accomplish the upgrade.

Once the ticket is created, the on duty engineer should add the dependency to the dependabot.yml igmore config, and include a comment that references the ticket.

These tickets should be triaged as a regular part of the team's planning sessions.

Define an SLA for on duty

While the metrics that you have set will help you keep track of your progress over the long term, I'd recommend adding an SLA to make sure that your team is tracking towards that metric over time. One SLA that I like for this "0 open Dependabot prs at the end of the on duty week." This doesn't mean that all of the dependencies have been upgraded, but it means they have been triaged and tickets have been added for them, and Dependabot can open a new set of prs the next week.

I've found that this process works quite well. It ensures that dependency upgrades get spread around the team, and also helps to reduce the number of outdated dependencies over time. It also allows us to catch upcoming major upgrades early and slot them into our roadmap.

Do you have a different process? I'd love to hear about it! Reply to this email and let me know.