Verification Loops for Control Coding

I write a lot of software. Lately, I've been doing so via Control Coding--a term I've been testing out that means something like "vibe coding, but with professional software engineering control".

When building software in this new way, I've begun to think of formatting, linting, type checking and testing as a subset of "verification." In other words, mechanical processes that verify a program's correctness.

In general, I want it to be fast and concise, and for these disparate verification systems to be interrelated. If one fails, they should all fail fast together so I can fix it and move on to the next issue.

To that end, I wrote a small npm library called @halecraft/verify. Its purpose is to unify the various linting, testing, typechecking, and any other verifying you do into a robust, quick loop. Here's a video explainer:

Each project you verify will need its own verify.config.ts file. You can use pnpm exec verify --init to initialize a new template config file for your project.

Here's an example of a more detailed one from one of my projects (it uses biome for formatting and linting, tsgo for fast type checking, and vitest for tests):

import { defineConfig } from "@halecraft/verify"

export default defineConfig({
  tasks: [
    {
      key: "format",
      run: "./node_modules/.bin/biome check --write --error-on-warnings .",
      parser: "biome",
    },
    {
      key: "types",
      parser: "tsc",
      reportingDependsOn: ["format"],
      children: [
        {
          key: "types:app",
          run: "./node_modules/.bin/tsgo --noEmit --skipLibCheck",
          parser: "tsc",
        },
        {
          key: "types:test",
          run: "./node_modules/.bin/tsgo --noEmit --skipLibCheck -p tests/tsconfig.json",
          parser: "tsc",
        },
      ],
    },
    {
      key: "test",
      run: "./node_modules/.bin/vitest run --project unit",
      parser: "vitest",
      reportingDependsOn: ["format", "types"],
    },
  ],
})

With this file, you can run 4 concurrent verification tasks at once.

Since we've added reportingDependsOn settings in this example, (e.g. types depends on format) then if the very fast biome formatting check fails, the types task will fail fast, and you can move on quickly to fix the formatting. Then retry.

In the future, I imagine there will be even more types of verification systems (design system constraints for example) as we formally and informally work towards correctness as an opposing force to LLMs that generate both usefulness as well as incorrectness in code.