You know that feeling when you publish a website, and three months later someone tells you half the links are broken? Or worse - when you're in the middle of a deployment and you know there are busted links somewhere, but you have no idea where?

When working on API reference documentation for Google's APIs, our team ran into this a little too frequently. Enough times that I built linkinator - a tool that crawls websites and checks for broken links. It's worked well enough for me for years, but here's the thing: running a link checker from the command line is kind of a chore.

A few years ago, npm introduced the notion of a package-lock.json. The purpose of the file is to provide a manifest that calls out the exact version of every package in your tree, the last time npm install was run. After running npm install, you're going to see a message like this:

npm notice created a lockfile as package-lock.json. You should commit this file.

As someone who works on developer tooling - GitHub is the holy grail of data sets. There's just so much code out there, written by so many people, for so many reasons. I've often wished I could just clone all of the data on GitHub, and then write scripts to process the data for various reasons:

• What are the top 1k npm modules used with Node.js apps? We want to know this so we can test them with App Engine.

In March I had the chance to talk at GCP Next on Node.js @ Google. This is a fun little tour of what Google Cloud has to offer Node.js developers.

Timeline​

I find dependency management and package managers interesting. Each language has its own package manager, and each one has characteristics that are specific to that community. NuGet for .NET has great tooling and Visual Studio support, since that's important to the .NET developer audience. NPM has a super flexible model, and great command line tools.

In a lot of ways, golang is a little quirky. And that's awesome. However - I've really struggled to wrap my head around dependency management in Go.