🐛 Upgrade staticalize to 0.3.0 so the sitemap is valid

[taras]

Motivation

Every sitemap this site has deployed is invalid. Staticalize wraps each <loc>
in <urls> rather than <url>, which is not the
sitemaps.org schema, so crawlers are
handed a document whose entries they have no reason to understand.

It went unnoticed because staticalize's own reader accepts either spelling
(xml.urlset.url ?? xml.urlset.urls), so a site staticalized twice round-trips
its own invalid output. thefrontside/staticalize#14 has the details;
thefrontside/staticalize#15 fixes the writer, and 0.3.0 is the first release
that carries it; 0.3.1 adds the fixes that came out of adopting it.

Approach

• deno.json — the staticalize task moves from 0.2.6 to 0.3.1 on npm
• .github/workflows/deploy.yaml — the downloaded binary moves from v0.2.7 to
  v0.3.1, in both the preview and the production job
• deno.lock — regenerated for the new version

The task takes staticalize from npm rather than jsr. Deno's minimum
dependency age refuses a jsr version for its first 24 hours, so a jsr specifier
blocks the task on the day of every staticalize release. npm resolution is not
subject to it. The package publishes a bin rather than a /cli export, so the
specifier loses its subpath, and the jsr entry the lockfile was carrying goes
away with nothing referencing it.

0.3.0 briefly required --retries, which was itself a bug
(thefrontside/staticalize#19). 0.3.1 restored the default
(thefrontside/staticalize#20), so the task does not pass it. The workflow keeps
its explicit --concurrency=25 and --retries=5, which predate all of this.

Two other fixes ride along in 0.3.0, neither of which changes anything here:

• the path component of --base is honoured — this site's base is
  https://frontside.com, which has no path
• self-referencing urls are rewritten outside HTML as well, not only inside it

--site still works, despite --help now presenting the site as a positional
argument. I checked rather than assumed.

Tests

Served a two-page site with a valid sitemap and staticalized it with both
versions:

0.2.6, what this site runs today

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <urls>
    <loc>https://example.com/</loc>
  </urls>
  <urls>
    <loc>https://example.com/about</loc>
  </urls>
</urlset>

0.3.0, this PR

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/</loc>
  </url>
  <url>
    <loc>https://example.com/about</loc>
  </url>
</urlset>

Note on the lockfile

The lock change is now a pure deletion: with the task on npm, nothing references
jsr:@frontside/staticalize and its 18 lines go. An earlier revision of this PR
also rewrote a few unrelated dependency lists, which is gone.

deno check main.tsx reports type errors on this branch; it reports the same
ones on production without these changes, so they are unrelated and I left
them alone.

The other consumers have landed

Every site this one proxies was on an affected version and deploying invalid
sitemaps. All three have merged:

repo	change	status
thefrontside/frontside.com	0.2.6 → npm 0.3.1, binary v0.2.7 → v0.3.1	this PR
thefrontside/effection	npm 0.3.1, binary v0.3.1, --canonical	thefrontside/effection#1255 merged
thefrontside/interactors	npm 0.3.1, binary v0.3.1, --canonical	thefrontside/interactors#333 merged
thefrontside/graphgen	npm 0.3.1, --canonical	thefrontside/graphgen#74 merged

Each of them also moved to --canonical, so it names this site as the original
rather than claiming its own Netlify origin. This site is the one they name, so
it needs no --canonical of its own.

That also settles the proxy. Keeping their sitemaps on --base means the
entries stay site-relative, so mounting them under /effection, /interactors
and /graphgen works exactly as it always did:

effection.netlify.app/sitemap.xml      <loc>https://effection.netlify.app/</loc>
interactors.netlify.app/sitemap.xml    <loc>https://interactors.netlify.app/</loc>
graphgen-data.netlify.app/sitemap.xml  <loc>https://graphgen-data.netlify.app/</loc>

An earlier run of this PR failed with 519 /effection/effection/… 404s. That
was thefrontside/effection#1248 pointing Effection's --base at
frontside.com/effection, which is what thefrontside/staticalize#22 and
thefrontside/effection#1255 undid. #509 was opened to make the proxy tolerate
it and is no longer needed.

[github-actions]

🚀 Deploy Preview Ready!

• Stable Review Link: https://pr-508--frontside.netlify.app
• Latest Commit Snapshot: https://6abd12579802bcf2b07cb416--frontside.netlify.app

Frontside

Frontside creates cohesive developer experiences for Cloud Native Teams

Frontside

Frontside creates cohesive developer experiences for Cloud Native Teams