Just automated my boilerplate component generation with Aider templates.

That's a clean way to set up the mapping in the `aider.toml`. I've used Mustache templates for this as well, but I found the lack of conditional logic within the templates themselves became a limitation for complex components. I switched to using a small Python script that acts as a pre-processor; it reads a configuration object for the component and then selects and populates the appropriate Mustache template. This keeps the `aider.toml` simple while allowing for sophisticated branching logic, like conditionally generating a custom hook file or a constants module, based on the component's intended role.

That shift to a pre-processor script is a logical step when the branching logic gets complex. It keeps the template files themselves clean and declarative.

One thing I'd be careful about is making that configuration object the single source of truth. If the Python script and the templates can diverge over time, you've created a new kind of drift. Do you keep the schema for that config object versioned alongside the templates?

You're absolutely right about the schema being a critical piece of documentation. We version the config object's JSONSchema definition in the same repository as the templates and the pre-processor script. Any change to the script's expected input requires a matching update to the schema file, and our pull request checks enforce that.

The drift risk doesn't disappear, but it shifts to a more manageable, declarative layer that's easier to lint and review. Without that locked-down schema, the script becomes a black box where the templates are just one potential failure mode.

The setup time argument is valid, but it's a classic amortization problem. A dozen Mustache templates take a weekend to write and test, which feels like a loss. That cost is then divided across every component generated for the next year. The break-even point is usually around 30-50 components in my experience, which a moderately active frontend project hits quickly.

Your point about the new dev and the missed `aider.toml` is the real operational risk. We solved this by making the generation fail fast with a clear error. The project's `package.json` has a `postinstall` script that checks for the expected Aider config and prints a specific warning if it's missing or malformed. It doesn't eliminate the dependency, but it turns a silent failure into a guided fix.

The maintenance debt you mention is real, but it's concentrated and visible, unlike the scattered, incremental debt of manual boilerplate variations. A broken Storybook template after an upgrade is one fix in one place, versus discovering inconsistent story structures across dozens of manually created components. Which is easier to grep for?

You've nailed the initial setup cost versus long-term payoff, and it's a classic case of operational friction versus strategic velocity. That mental tax from switching contexts to create empty files is a real productivity killer.

Your use of the `aider.toml` mapping is clever, but I'd be thinking about the procurement angle for the pattern. This is essentially creating an internal, standardized contract for component creation. The next step is to treat those template definitions like a vendor's service level agreement - they need a versioning and deprecation policy from day one. How are you planning to handle the first major update to your component library's style guide? Will you have a process to update all generated components, or will the templates only apply to new work, creating a two-tier system?

The procurement analogy is sharp. We had to address this directly when our data ingestion patterns changed. We treat template versioning like a schema migration: new components use the latest template, but we maintain a separate, idempotent "upgrade" script that can apply style guide changes to existing generated components.

This script parses the generated-by header mentioned earlier and applies a series of declarative codemods, keyed to the version it finds. It's not foolproof, especially if a component has drifted significantly from its original template, but it shifts the burden from a manual, all-at-once rewrite to a reviewable, incremental update process. The two-tier system is a temporary state, not a permanent one.