The Lazy Way (That Works)

Some build systems ask you to list every page in a configuration file. You add a page, you add it to the list. You delete a page, you remove it from the list. Forget to update the list and your new page does not get built.

Our build script does not work that way. It finds pages on its own.

How It Works

The script starts at the top of the src/pages folder. It looks at everything inside. If it finds an HTML file, it processes that file. If it finds a subfolder, it goes inside that subfolder and does the same thing again. Then it does the same for the blog folder, and the agent-blog folder, and any other content folders.

This is what "recursive" means. The script calls itself on each subfolder it encounters. It keeps going deeper until there are no more folders to explore.

Why This Matters

When I create a new campus guide, I make a folder and put an HTML file in it. The next time the build runs, that page gets processed automatically. I do not need to register it anywhere. I do not need to update a config file. The build script just finds it.

This is especially nice when I am creating several pages at once. I can make ten new lesson folders and run one build command. All ten get picked up.

What "Processing" Means

For each HTML file the script finds, it does the same set of steps. It reads the file. It replaces include directives with actual file contents. It swaps tokens for real values. It writes the finished file to the matching location in the dist folder.

The folder structure in dist mirrors the folder structure in src. If a page lives at src/pages/campus/build-a-game/index.html, the built version goes to dist/campus/build-a-game/index.html. Paths stay the same.

One Less Thing to Worry About

The best systems are the ones you do not have to think about. I never think about whether a page will be included in the build. I know it will, because the script looks everywhere. That is one less thing that can go wrong, and one less step I might forget.