refactor(components): reference the shared heading-level arguments

[markdumay]

Draft — blocked on gethinode/mod-utils#361 being released and bumped here. Until then tests/templates fails, by design; see below.

What

Reduces heading-level and heading-class in data/structures/section-title.yml from full inline definitions to release-only overrides:

  heading-level:
    release: v3.19.0
  heading-class:
    release: v3.19.0

Why

Both shipped in v3.19.0 as complete inline definitions. They are common arguments, and common arguments are defined once in mod-utils _arguments.yml — use-title, the boolean heading-level replaces, has always been a single entry there. ArgsSchema.html merges the global definition with local overrides, so a key that only pins release: inherits type, optionality and comment. That is the prevailing shape: 98 arguments across these structure files already use it, card-group.yml alone accounting for twelve.

Keeping the definitions inline also duplicates them into every consumer — gethinode/mod-blocks#193 currently repeats the same six-line block fourteen times, which is the immediate motivation for fixing the source.

Sequencing

1. feat(arguments): add heading-level and heading-class mod-utils#361 merges and releases
2. bump mod-utils here, then this merges
3. mod-blocks#193 drops its sidecar definitions in favour of blueprint keys

Against the currently vendored mod-utils v6.8.5 the schema has no type for either key, so assets/section-title.html reports Invalid arguments and the section-title assertions fail. That is the expected pre-release state, and it is exactly what the template tests added in #2116 are there to catch.

Verification

Rendered against a local mod-utils carrying the two definitions, through a workspace use. All six argument shapes are byte-identical to shipped v3.19.0:

args	rendered
unset	<div id="a" class="display-4 text-body pt-1">
use-title: true	<h1 id="b" class="display-4 text-body pt-1">
heading-level: 2	<h2 id="c" class="display-4 text-body pt-1 mt-0 mb-0">
heading-level: 0	<div id="d" class="display-4 text-body pt-1">
heading-level: 1, heading-class: ""	<h1 id="e" class="display-4 text-body pt-1">
heading-level: 9	warns, <div id="f" class="display-4 text-body pt-1">

The unset row is the one that matters most: _arguments.yml deliberately sets no default:, so an omitted level stays nil and the legacy use-title fallback keeps working.

🤖 Generated with Claude Code

[netlify]

✅ Deploy Preview for gethinode-demo ready!

Name	Link
🔨 Latest commit	910cad0
🔍 Latest deploy log	https://app.netlify.com/projects/gethinode-demo/deploys/6a7336c1e2563300083aebd3
😎 Deploy Preview	https://deploy-preview-2122--gethinode-demo.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[markdumay]

Unblocked — gethinode/mod-utils#361 merged and released as v6.9.0, which contains only that commit, so the module bump here isolates exactly this refactor.

Now green against the released module:

• test:templates exits 0. Before the bump it failed with Invalid arguments and got=%!q(<nil>) on the section-title assertions, which is the pre-release state this PR described.
• hugo -s exampleSite builds clean, 122 pages.

The example-site build is byte-for-byte identical to main — zero differing files across all 122 pages, comparing main (mod-utils v6.8.5, inline definitions) against this branch (v6.9.0, shared definitions).

One caveat worth recording for anyone reproducing that comparison: pnpm mod:vendor is a no-op when _vendor already exists and looks current, so seeding a worktree by copying _vendor from another checkout leaves stale module content in place and the skip is silent. That produced a spurious three-file diff on the simple-datatables bundle in my first run. pnpm mod:vendor:force is what actually re-vendors.

[markdumay]

🎉 This PR is included in version 3.19.3 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀