🐛 Specify canonical url as frontside.com/graphgen with staticalize

[taras]

Motivation

frontside.com proxies this site at /graphgen and serves the same pages, so the
two origins are duplicates of each other. Nothing says which one is the
original:

• the docs emit no <link rel="canonical"> at all
• the deploy staticalizes with --base=https://graphgen-data.netlify.app, so
  every internal link and every sitemap entry names the hosting url rather than
  the one readers visit

Two identical sites and no signal is how they end up competing for the same
searches instead of counting as one page. Neither origin has a robots.txt
either, so nothing else settles it.

Effection had the same problem and thefrontside/effection#1248 fixed it;
thefrontside/interactors#333 does the same for Interactors. Graphgen is the
worst of the three, because it never had a canonical to point anywhere.

Approach

Two small pieces.

The docs pages name the url they are read at, built from the request rather
than hardcoded, so a local crawl still names localhost and only a deploy names
frontside.com:

let canonical = new URL(props.url.pathname, props.url.origin).href;
…
<link rel="canonical" href={canonical} />

Only routes/docs/[...slug].tsx needs it. index.tsx is a 307 redirect with no
markup, and [name].tsx is a demo page that is not in the sitemap.

The base is that url, so staticalize rewrites the canonical along with the
links and the sitemap:

-  deno run -A jsr:@frontside/staticalize@0.3.0/cli … \
-    --base=https://graphgen-data.netlify.app --retries=3
+  deno run -A npm:staticalize@0.3.1 … \
+    --base=https://graphgen-data.netlify.app \
+    --canonical=https://frontside.com/graphgen

staticalize 0.3.1 rewrites it onto --canonical while the rest of the build —
links, assets, the sitemap — stays on --base. So the Netlify copy remains
readable on its own and its sitemap still names the origin it is served from,
which is also what keeps frontside.com's proxy mounting it correctly.

The task takes staticalize from npm rather than jsr. Deno's minimum
dependency age refuses a jsr version for its first 24 hours, and both deploy
jobs run this task, so a jsr specifier would fail every deploy on the day of a
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.

0.3.1 also restored the default for --retries, so the flag 0.3.0 forced us to
pass goes away with it.

fix-static-css.ts still runs afterwards and is unaffected: it walks .html
files replacing Twind CSS and state, and does not touch urls.

Tests

Ran the site and staticalized it against the new base:

13 pages  3 assets   (no errors)

<link rel="canonical" href="https://frontside.com/graphgen/docs/introduction">
<link rel="canonical" href="https://frontside.com/graphgen/docs/basics">

sitemap: https://frontside.com/graphgen/
         https://frontside.com/graphgen/docs/introduction
         https://frontside.com/graphgen/docs/basics
         spelled <url>, per #73

Served locally without the base, the same page correctly names localhost:

<link rel="canonical" href="http://127.0.0.1:8000/docs/introduction"/>

Rebased onto v1 now that #75 is in, which is also what makes this runnable:
www/deno.lock had stale integrity hashes and the site would not start
without --no-lock. It does now, so this was verified through the real
deno task staticalize, fix-static-css.ts and all:

✅ Fixed 8 pages, 5 pages were already OK

<link rel="canonical" href="https://frontside.com/graphgen/docs/introduction">
sitemap: https://graphgen-data.netlify.app/…

deno fmt --check, deno lint and deno task test (10 passed, 82 steps) are
all green on the rebased branch.

Merge order

None. Keeping the sitemap on --base means its entries stay site-relative, so
frontside.com's proxy mounts them exactly as it always has — which is the whole
point of the --base/--canonical split. thefrontside/frontside.com#509 is
still worth landing as insurance, but this no longer waits on it.

Worth confirming

This assumes frontside.com/graphgen is the intended public home and
graphgen-data.netlify.app is hosting. That matches how Effection and
Interactors are set up. If Graphgen is meant to stand on its own domain instead,
the right change is the opposite one — keep the base and stop proxying it — and
this PR should be closed.

[github-actions]

🚀 Deploy Preview Ready!

• Stable Review Link: https://pr-74--graphgen-data.netlify.app
• Latest Commit Snapshot: https://6abcf853c7bfd50dc30b8a4a--graphgen-data.netlify.app

Introduction | graphgen docs

Docs intro

Introduction | graphgen docs

Docs intro