For three articles, we took Front Matter as it comes out of the box: installed, finely configured, used day to day. Nothing we added to the tool itself.

This article changes register. We are going to extend Front Matter: teach it to pre-fill articles, to insert ready-made blocks, to expose our own buttons in the panel, and to store its configuration across several files rather than one 450-line frontmatter.json. This is the moment the extension stops being a form and becomes part of the repository's tooling.

In the previous article, we built a custom content type: the form knows our fields, the lists feed themselves, manual typing has almost disappeared. Configuration is behind us.

This article is about what comes after: the weeks when you no longer open frontmatter.json. Writing, finding, classifying, illustrating — the routine. This is where the real question asked at the start of this series plays out: does the tool hold up once the novelty wears off?

In the previous article, we saw why Front Matter CMS is worthwhile on a Docusaurus project. Let's get practical.

Installation takes two minutes and the extension guides us through it. The real work — the part that makes the difference between a gadget and a tool you use every day — is to match the CMS to your own front matter schema. And, as we'll see, to have the courage to model only what actually serves a purpose.

If you have been maintaining a Docusaurus site for a while, you know this scene: opening an .mdx file, scrolling all the way up to edit the front matter by hand, and hoping you did not make a typo on sidebar_label or forget a comma in tags. No validation, no overview of what is published, in draft or outdated. And to check the rendering, you have to run npm run start and navigate to the right page.

That is exactly the gap Front Matter CMS fills.

My blog was quietly shipping 13.7 MB of images. A few PNGs weighed over a megabyte, and several WebP files were surprisingly heavy — over-sized dimensions and default encoder quality. Heavy images hurt load time, Core Web Vitals, and ultimately SEO. So I built a small local Docusaurus plugin that optimizes every image at build time, and it cut the deployed images almost in half (-49%) — without touching a single source file.

This article walks through the plugin: how it hooks into the build, how a content-hash cache makes it incremental (already-optimized images become a reusable artifact), and the real numbers it produced.

For a long time this blog had no linter and no formatter. Files drifted into different styles (some indented with 4 spaces and single quotes, others with 2 spaces and double quotes), and nothing was watching for the small mistakes that slip into any React codebase. So I finally added ESLint and Prettier — and to my surprise, the linter immediately found real bugs that had been hiding in plain sight.

This article explains what these two tools actually do, how I configured them for a modern Docusaurus (React 19, a few TypeScript components, custom plugins), and — the fun part — the concrete issues ESLint caught in my own code.