You've been there. Need a new microservice, maybe a quick CLI tool. You remember that perfect template you stashed away, or maybe you grab one off GitHub. git clone, run the generator... npm install... FAILED. Or cargo build... FAILED. Dependencies drifted, build steps changed, the world moved on. The template lied. Template rot is real, and it wastes our time debugging boilerplate before we even write line one of our actual project.
I got seriously fed up with this cycle. I've automated the heck out of things before, and this felt like a problem begging for a better process. Tools like Cookiecutter, Yeoman, dotnet new, etc., are powerful for generating files, absolutely. But ensuring the template itself is currently valid? That often felt like an afterthought, bolted on with external CI maybe, if you were lucky.
Spawn Point: Not Just Copying, Validating.
So, I built Spawn Point (spawnpoint). Yeah, another scaffolding tool. But this one's built in Rust (because performance is nice, and I like Rust) with one core obsession: making templates prove they work.
The centerpiece isn't just the generate command, it's spawnpoint validate <lang> <template>.
Think about it: how do you really know a template is good? You generate it, cd into it, and run the build, run the tests, run the linter. Spawn Point just automates that.
Every Spawn Point template can have a validation section in its scaffold.yaml manifest. You tell it:
Here are some testVariables (like dummy project names, flags to enable/disable features).
Here are the steps to run: npm install, cargo build --release, gradle test --no-daemon, wasm-pack build, eslint ., whatever proves this template generates a working project right now.
When you run spawnpoint validate, it doesn't trust the template's README. It:
Generates the project in a clean, temporary spot using those test variables.
Runs the gauntlet – executes every single validation step you defined.
Tells you "Pass" or "Fail" and exactly which command broke if it fails.
For anyone maintaining templates, this is like having a built-in linter and integration test suite for the template itself. Stick spawnpoint validate in your template repo's CI. Template rot doesn't stand a chance. You know if merging that dependency update broke the template's ability to generate a working project. That’s the kind of reliability I wanted.
Flexibility Without the Headache
Okay, validation is key, but it still needs to be flexible. I didn't want to embed a complex template language ({{#if}}, {% for %}) inside my source files – that often makes the template itself harder to read or even invalid until generated.
Spawn Point's approach:
Dumb Placeholders: Use unique values in your files (like "---PROJECT_NAME_PLACEHOLDER---" or com.example.placeholdergroup). The scaffold.yaml maps your variables (projectName, projectGroup) to these exact strings. Simple substitution, less syntax noise.
Automatic Transformations: Need projectName as MyProjectName (PascalCase) and my-project-name (kebab-case)? Define it once in the YAML, ask for transformations, and use the specific placeholders (__PascalProjectName__, --kebab-project-name--). The heck crate does the heavy lifting.
Filename/Path Magic: Need src/main/java/.../__PascalProjectName__.java? It can substitute variables in filenames and directory paths too.
Conditional Files: Only need that Dockerfile if the user says yes? Easy, use a boolean variable and conditionalPaths in the YAML.
Hooks & Environment: Need to git init or run npm install after generation? Use preGenerate / postGenerate hooks. These run via sh -c and, crucially, inherit your PATH and environment, so calling tools like node, cargo, mvn, git just works without hassle. We use the solid duct crate to handle running these commands cleanly.
Where It's At
Spawn Point is functional. The core generation and validation loops are solid. I've built out examples for Node.js, Rust (CLI, Leptos/WASM), Java (Gradle, Maven) to prove the concepts.
Is it perfect? Heck no. It's a work in progress. Non-interactive variable flags for generate are needed. More examples would be good. The error reporting could be fancier. There are probably bugs I haven't found.
But the core idea – making templates continuously verifiable – feels right to me. If you've felt the pain of template rot and want a tool that prioritizes fixing that, maybe give Spawn Point a look.
Check out the GitHub or Crates.io, kick the tires on the validate command with the example templates. See if it clicks. I didn't build it to compete; I built it because I needed templates I could actually trust. Maybe you do too.