🐛 Use --canonical and --base from new staticalize - #1255
Merged
Merged
Conversation
commit: |
Contributor
|
🚀 Deploy Preview Ready!
|
taras
force-pushed
the
tm/canonical-via-staticalize
branch
from
September 28, 2026 21:47
67994f4 to
de50809
Compare
#1248 pointed the production `--base` at frontside.com/effection to get the canonical right. That moved every other url with it, including the sitemap, and frontside.com prefixes `/effection` onto a proxied sitemap whose entries now already carried it. 519 urls 404'd and its deploys have failed since. staticalize 0.3.1 separates the two. `--base` is where the bytes are again, so the Netlify copy is readable on its own and its sitemap says so; `--canonical` is the address readers arrive at, and only the urls that name the page follow it. That makes the site's own copy of the idea redundant. `canonical()` had been rebasing onto a configured origin, which is exactly what staticalize now does, so it is gone along with the `base` field and the `--base` option — which also ends this project having two different flags by that name. What `app.html.tsx` needs is the url of the page being served, so that is what it asks for: `currentUrl()`, a plain operation rather than a member of the api. Calling it `canonical` would have named it after what the crawl does to it. Dropping the member also drops the `Api<UrlApi>` annotation, which only existed because a member reached back through the api for another. Verified against the real site: canonical, og:url and both hreflang alternates name frontside.com; og:image and the sitemap name Netlify; the sitemap has no doubled paths; and llms.txt still names the published site, which is what #1248 wanted. 0.3.1 also restored the default for `--retries`, so the flag 0.3.0 forced us to pass goes away with it.
taras
force-pushed
the
tm/canonical-via-staticalize
branch
from
September 28, 2026 22:16
de50809 to
688df50
Compare
taras
changed the title
Deno's minimum dependency age refuses a jsr version for its first 24 hours, which is why the pagefind route sat on 0.2.7 while the deploy moved on: the comment on that pin says pinning it forward would make the dev server wait out the policy on the day of a release. npm resolution is not subject to it, so both callers can name the version the deploy uses. `npm:staticalize@0.3.1` is the same program — the package publishes a `bin` rather than a `/cli` export, so the specifier loses its subpath. Verified both callers against the running site: the deno task and the exact command the pagefind route execs each crawled 505 pages and 21 assets with no errors.
cowboyd
approved these changes
Sep 30, 2026
taras
added a commit
to thefrontside/graphgen
that referenced
this pull request
Sep 30, 2026
frontside.com proxies this site and serves the same pages, so the two origins are duplicates of each other. Nothing said which one is the original: the docs emitted no canonical at all, and the deploy staticalized with `--base=https://graphgen-data.netlify.app`, so every link and every sitemap entry named 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. The docs pages now name the url they are read at, built from the request so that a local crawl still names localhost. staticalize 0.3.1 rewrites it onto `--canonical` while the rest of the build stays on `--base`, so the Netlify copy remains readable on its own and its sitemap still says so. Only `routes/docs/[...slug].tsx` needs it: `index.tsx` is a 307 with no markup, and `[name].tsx` is not in the sitemap. staticalize comes 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 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. thefrontside/effection#1255 and thefrontside/interactors#333 make the same move; `fix-static-css.ts` only rewrites Twind css in html and is unaffected.
This was referenced Sep 30, 2026
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
#1248 pointed the production
--baseathttps://frontside.com/effectionsothat the canonical url would be right, but it also changed every self-referencing url including the sitemap.
Approach
Added
--baseand--canonicalURL tostaticalize@0.3.1.This allows to rewrite all local URLs to URLs with prefix and canonical to the remote URL.
Related
mounting idempotent, which is cheap insurance against this recurring