From one framework to fifty modules

go-tool-base started as one framework and is now the place most of fifty-odd modules were extracted from. This is how that went: what got graded, what refused to leave, the config package that had to be rebuilt to let anything go, and what the split costs every time a core changes.

10 posts

Start here

Every package scored before anything moved, and the four that were never going to leave.

  1. I graded every package for how badly it wants to leaveTwenty-seven packages, four marks each, out of ten. The interesting column wasn't the one I expected, and one row explained the whole programme. Pioneering
  2. The packages that didn't want to leaveEveryone writes up the modules that came out. The decisions that mattered were the four packages I decided to leave exactly where they were. Pioneering

Doing the extraction

A playbook that only became real on the hard case, and the border that let a package leave without dragging config along.

  1. The extraction playbook only got real when chat leftI wrote the process document before doing the hard one. Then the hard one went through it and rewrote a step. Pioneering
  2. Config is a border, not a chainI built a boundary so I wouldn't have to move my config package. Then I moved it anyway, and the boundary is the only reason that didn't hurt. Pioneering

Config, rebuilt

Writing a value back without wrecking the file, one format per module, and the YAML engine underneath.

  1. The writer I added, and the Viper I deleted by accidentI set out to add a config writer and keep Viper. I ended up keeping the writer and deleting Viper, and I didn't notice until it was already gone. Pioneering
  2. A format per module, not a fatter config coreViper reads a dozen extensions. Mine reads one, and the other formats live somewhere else entirely. Here's what that bought, measured rather than asserted. Pioneering
  3. YAML has comments for a reasonyamldoc is the editing half of YAML for Go: change one key and every byte you did not touch comes back exactly as it went in, comments included. It now has an engine of its own, and the numbers to show why. First Light

Config, the tutorials

Two walkthroughs, each ending with something that runs: a layered store that knows where a value came from, and a project's settings over the user's.

  1. Layering config without losing where a value came fromFour places a config value can come from, and the only question that matters at the wrong end of an incident: which one won, and why. Twenty minutes, one module, no services. Orienteering
  2. When a project's config inherits yoursTwo configs for one tool, the user's and the project's, and no rule anywhere about which one wins. Twenty minutes to make one a layer of the other and keep a straight answer about where every value came from. Orienteering

The bill

The split was the right call, and it charges again every time a core module changes.

  1. The bill for fifty-one modulesChange one line in the tls module and you've signed up for twelve releases. That's not a bug in the architecture, that's the architecture. Pioneering

Where to next

Everything, newest first → Follow this guide by RSS