Building a Toolbox for My Website

A little while ago, starting this article would have involved rather more manual work. It didn’t occur to me to write a tools for this. After all, how much friction can there be in creating a new Markdown (well, MDX) file when I want to write an article? Or adding a new component to the sites UI system? Or scan for images I intended to use but were left unused?

Well, more friction than I would have liked! Even a small amount of friction, with enough repetition, is annoying. Which is where the “toolbox” comes in. I think it’s a pretty nifty name, if overused. This toolbox primarily makes four things easier:

• Discoverability. I already had some small scripts, but remembering their names and how to invoke them was starting to grate on me. This is poor developer experience.
• Standardisation. The scripts I already had had grown pretty organically, as they tend to do. One script would create or update a file differently from another script. Or it would handle command-line arguments differently from the next one, etc.
• Automation. Creating a new article or note, creating a new component with documentation and tests, and creating a new branch with the same name as an article are now all one command away. This also helps with consistency.
• Interactivity. Some of the tools are much nicer to use with prompts and choices, like selecting an article from a list, choosing from existing tags, or entering the title of a new article and having it converted to AP-style title case.

I realised I would need both a task runner and a templating tool. The task runner would help with discoverability, while the templating tool would handle generating or updating files consistently. I was a little concerned that solving my problems with two tools might introduce more friction than I was trying to remove in the first place. As it turns out, I am very happy with these tools and my concerns were unfounded.

It had been some time since I last looked at the templating tools available for JavaScript, and I found much the same malaise as when I last looked into this a few years ago. The whole area feels oddly stagnant.¹ I chose Plop which I’m fairly happy with. For the rask runner, I evaluated two options.

• Task. This was the first one I tried, as it seems to be popular. I was happy with it, and its use of YAML, controversial as that may be, was actually a plus for me. I don’t particularly enjoy using bespoke DSLs unless they have good tooling and editor support.
• Just. I switched to Just almost immediately after reading a Hacker News comment. Just will pass along extra command line arguments. It does have a downside of once again being a bespoke DSL, vaguely inspired by makefiles. Still better than Terraform with its psuedo-JSON.

Overview#

My “justfiles” are organised into modules. Each one fulfils a particular role. There is some overlap, such as article having commands related to updating an article, while new having commands to create a new article or note. I suppose I could instead have one file.

Just is just the command runner in this setup, and it invokes Plop. Plop is a template-based generator for creating new files, but it can also edit existing files. Such as, updating fields in files like YAML frontmatter in a Markdown file. The templates are a typical Handlebars syntax.

1
lloydatkinson.net
2
├── justfile
3
├── src
4
└── toolbox
5
    ├── article.just
6
    ├── deploy.just
7
    ├── format.just
8
    ├── image.just
9
    ├── links.just
10
    ├── new.just
11
    ├── plopfile.ts
12
    ├── plop-templates
13
    │   ├── article.hbs
14
    │   ├── component.docs.hbs
15
    │   ├── component.hbs
16
    │   ├── component.snippet.hbs
17
    │   ├── component.test.hbs
18
    │   ├── note.hbs
19
    │   └── page.hbs
20
    ├── test.just
21
    └── ui.just

Writing content#

The first tools I built automated the creation of articles, notes, and pages. Articles and notes are MDX files, while a page is a particular type of Astro component used for a root-level page on the site. I discuss later a command for creating UI type components used within those pages.

1
PS E:\Source\lloydatkinson.net> just new
2
Available recipes:
3
    article        # Create a new article
4
    article-branch # Create a new article on a new branch from master
5
    note           # Create a new note
6
    page           # Create a new page, optionally inside a new or existing directory
7

8
PS E:\Source\lloydatkinson.net> just new article-branch
9
? Article title: Building a Toolbox for My Website
10
? Description (optional): I built a small collection of tools to automate repetitive tasks and make working on my website easier.
11
? Pick existing tags (optional): Astro, Automation, Static Sites, Workflows, Tools
12
? New tags, comma-separated (optional):
13
✔  createBranch Created and switched to branch post/building-a-toolbox-for-my-website
14
✔  ++ /src/content/article/2026/building-a-toolbox-for-my-website.mdx
15
✔  openInEditor Opened src/content/article/2026/building-a-toolbox-for-my-website.mdx in VS Code

The Plop template for an article looks like this. Note the conditional and iteration constructs. The tags property always exists, but is an empty collection should none be supplied.

1
---
2
title: "{{{yamlTitle}}}"
3
description: "{{{yamlDescription}}}"
4
dates:
5
    published: {{publishedDate}}
6
{{#if tagList.length}}
7
tags:
8
{{#each tagList}}
9
    - {{{this}}}
10
{{/each}}
11
{{else}}
12
tags: []
13
{{/if}}
14
status: draft
15
---

1
PS E:\Source\lloydatkinson.net> just new article-branch
2
? Article title: Reducing .NET AWS Lambda Cold Starts by Adding Memory
3
? Description (optional): A pleasantly simple fix that reduced cold-start time from ~7 seconds to ~2.5 seconds.
4
? Pick existing tags (optional): .NET, AWS
5
? New tags, comma-separated (optional): AWS Lambda
6
✔  createBranch Created and switched to branch post/reducing-dotnet-aws-lambda-cold-starts-by-adding-memory
7
✔  ++ /src/content/article/2026/reducing-dotnet-aws-lambda-cold-starts-by-adding-memory.mdx
8
✔  openInEditor Opened src/content/article/2026/reducing-dotnet-aws-lambda-cold-starts-by-adding-memory.mdx in VS Code

1
PS E:\Source\lloydatkinson.net> just new note
2
? Pick existing tags (optional): Astro, Tools
3
? New tags, comma-separated (optional):
4
✔  ++ /src/content/note/24.mdx
5
✔  openInEditor Opened src/content/note/24.mdx in VS Code

1
PS E:\Source\lloydatkinson.net> just article status
2
? Which article? Building a Toolbox for My Website (draft) (src/content/article/2026/_building-a-toolbox-for-my-website.mdx)
3
? New status: published
4
✔  setArticleStatus Set published and renamed src/content/article/2026/_building-a-toolbox-for-my-website.mdx to src/content/article/2026/building-a-toolbox-for-my-website.mdx

Creating components#

All components in my site start with this recipe. This recipe assumes they are design system components, hence the ui. For other one-off, article-specific components, my current workflow is to still run this recipe and move the files to the appropriate place. This itself is an opportunity for a recipe.

Take note of the <name>.<type>.<extension> convention I’m using here. Tests, documentation, and finally documentation snippets. These are used by my design system documenation to generate example usages of components.

1
src/ui/components/snippets
2
├── ButtonSolidTones.snippet.astro
3
├── ButtonSoftTones.snippet.astro
4
├── IconTones.snippet.astro
5
├── StackBasic.snippet.astro
6
├── StackAlign.snippet.astro
7
├── TextSizes.snippet.astro
8
├── TilesResponsive.snippet.astro
9
└── ... 96 more

I’m quite pleased with my implementation here. I use the same snippet to generate the code examples and render real component usage in the documentation pages, which keeps the two completely in sync. The idea is that for each use case, variant, or feature of a design system component, I write a snippet file.

1
PS E:\Source\lloydatkinson.net> just ui component
2
? Component name: Callout
3
✔  ++ /src/ui/components/Callout.astro
4
✔  ++ /src/ui/components/Callout.test.ts
5
✔  ++ /src/ui/components/snippets/CalloutBasic.snippet.astro
6
✔  ++ /src/ui/components/Callout.docs.astro
7
✔  formatWithBiome Formatted src/ui/components/Callout.astro, src/ui/components/Callout.test.ts, src/ui/components/snippets/CalloutBasic.snippet.astro, src/ui/components/Callout.docs.astro
8
✔  openInEditor Opened src/ui/components/Callout.astro, src/ui/components/Callout.test.ts, src/ui/components/snippets/CalloutBasic.snippet.astro, src/ui/components/Callout.docs.astro in VS Code

The following files are generated:

1
---
2
import Box from './Box.astro';
3
---
4
<Box><slot /></Box>

1
import { experimental_AstroContainer as AstroContainer } from 'astro/container';
2
import { describe, expect, it } from 'vitest';
3

4
import Callout from './Callout.astro';
5

6
describe('Callout', () => {
7
    it('renders', async () => {
8
        const container = await AstroContainer.create();
9
        const result = await container.renderToString(Callout, {
10
            slots: { default: 'Some content' },
11
        });
12

13
        document.body.innerHTML = result;
14

15
        expect(document.body.innerHTML).not.toBe('');
16
    });
17
});

1
---
2
import { extractSnippet } from '../foundation/snippet';
3

4
import Preview from './Preview.astro';
5
import CalloutBasicSnippet from './snippets/CalloutBasic.snippet.astro';
6
import CalloutBasicRaw from './snippets/CalloutBasic.snippet.astro?raw';
7
---
8
<Preview snippet={extractSnippet(CalloutBasicRaw)}>
9
    <CalloutBasicSnippet />
10
</Preview>

1
---
2
import Callout from '../Callout.astro';
3
---
4
<Callout>Example content</Callout>

Tidying up#

This is a group of recipes that helps me avoid forgetting to include images in an article or renaming images from the ugly names cameras tend to give them. It’s quite easy to forget to include an image on image-heavy posts, like the year-in-review posts I write.

1
PS E:\Source\lloydatkinson.net> just image orphaned
2

3
src/content/article/2022/images:
4
  src/content/article/2022/images/squash-merge-or-merge-commit.png
5
  src/content/article/2022/images/react-conditional-rendering.png
6

7
src/content/article/2023/images:
8
  src/content/article/2023/images/old-diagram.png
9

10
done - 3 orphaned images found

1
PS E:\Source\lloydatkinson.net> just image rename src/content/article/2026/images
2
IMG_249234.JPG -> img-249234.jpg
3
HEIC_42-0423.JPG -> heic-42-0423.jpg
4

5
done - 2 renamed, 0 skipped

Builds and deployments#

I don’t deploy my site manually; the Cloudflare app for GitHub handles it entirely instead of GitHub Actions, which I still use for everything else. I sometimes want to check deployment status, including preview branches and their URLs. These recipes use the Cloudflare API to do that.

1
PS E:\Source\lloydatkinson.net> just deploy status
2
success        production  master                         https://8569dff8.lloydatkinson-net.pages.dev (live: https://www.lloydatkinson.net)
3
success        preview     post/building-a-small-toolbox- https://06548f7c.lloydatkinson-net.pages.dev