AfterConfig Released to Change Vendor Config Files Without Editing Them
Aftermarket 0.4.0 adds AfterConfig, run as aftermarket config. It’s for the config file a vendor ships with its app, the one you have to change and every upgrade overwrites.
The usual fix is to edit the file and keep a note somewhere. Then the upgrade lands, the note gets forgotten, and the app runs on vendor defaults again. Or worse, someone copies the old file back over the new one and wipes out a setting the vendor added on purpose.
AfterConfig keeps your changes in a separate overlay file, and it never edits the vendor’s file at all.
An overlay
version: 1
base: 1.0/config.json
changes:
# Our reports run long. The vendor default was 30 seconds.
- set: {path: server.timeout, value: 120, expect: 30}
# No telemetry leaves our network.
- set: {path: telemetry.enabled, value: false, expect: true}
# Our database password.
- set: {path: database.password, value: from-our-vault}
# A setting the vendor doesn't have yet.
- set: {path: server.max_body, value: 10MiB, expect_absent: true}
Each change names a field by its dot path. Besides set there are delete, rename and copy, the same operations AfterPatch uses on JSON traffic.
The expect part is a guard: the value the change expects to find. apply writes the result to a file of your choosing, in one step, and refuses any path that leads back to the vendor’s file.
The point of the guards
When the vendor ships version 1.1 with a new default timeout, apply doesn’t quietly override it:
$ aftermarket config apply --overlay overlay.yaml --base 1.1/config.json --out config.json
overlay.yaml: 2 of 7 change(s) can't be applied to 1.1/config.json
line 8: set expects server.timeout to be 30, but the base has 60
line 14: set expects logging.format to be "text", but the base has "json"
nothing was written
The vendor changed two things your overlay relied on. Maybe the new timeout is fine. Maybe the vendor now does what your logging change did. That’s a decision for a person, so AfterConfig stops, names the lines, and leaves the old output as it was. Everything else the vendor changed in 1.1 comes through untouched.
What it promises
- The vendor’s file is never written, however
--outnames it: directly, through a link, or by another spelling of the path. - Nothing the overlay doesn’t name changes. Fields keep their place and value. An overlay with nothing to change gives back the vendor’s file byte for byte.
.envfiles keep every untouched line and comment. YAML keeps unquoted values and keys exactly as written, so an unquotedyesstill means the same to every YAML reader. - Every result is read back before it’s written. If it doesn’t hold exactly what was meant, nothing is written.
- Secrets stay out of sight.
checkanddiffand every error message showREDACTEDfor keys such aspassword,tokenorapi_key, and for user names and passwords inside URLs.
It reads JSON, YAML and .env files. TOML comes later. config check and config diff show what an overlay will do, and config test runs fixtures in CI.
The quick start has a fourth part that runs the example from the download archive. There’s also a case study that takes it through an upgrade. The full format is in the AfterConfig reference. How it was tested covers what the review found.