mirror of
https://github.com/hanzo-apps/hanzo.ai.git
synced 2026-10-30 14:58:08 +00:00
The import path is the site. The go tool asks for it with ?go-get=1 and reads one meta tag out of the answer; without that tag the toolchain says "unrecognized import path: no go-import meta tags" and there is nothing a caller can configure to get past it. The tag points at GitHub rather than the forge, and that is measured rather than preferred: an unauthenticated clone of git.hanzo.ai answers `could not read Username`, so a tag naming it would fail for everyone who is not us — including proxy.golang.org, which fetches anonymously and is what makes a module resolvable at all. This site is a static export, so there is no middleware to write the tag and it is page metadata instead. That turns out to be the better shape anyway: each module gets a page at its own import path, which is where a person who followed the import out of a stack trace already is. Nineteen of the names are product pages already; those pages are client components and cannot carry metadata, so the segment's layout does, off the same definition. A module is listed only where github.com/hanzoai/<name> answers 200 anonymously AND the repository name equals the module name — 66 of 93 candidates. Publishing a path that resolves to nothing is worse than publishing none: the tool tells the caller the path is real and then fails at the clone.
14 lines
530 B
TypeScript
14 lines
530 B
TypeScript
import type { Metadata } from 'next'
|
|
|
|
import { goImport } from '@/lib/go-modules'
|
|
|
|
// This path is a product page AND the import path of a Go module. The page is a
|
|
// client component and cannot carry metadata, so the segment's layout does: the
|
|
// tag is invisible to a reader and is the whole of what `go get hanzo.ai/cloud`
|
|
// needs. Defined once in lib/go-modules.
|
|
export const metadata: Metadata = { other: goImport('cloud') }
|
|
|
|
export default function Layout({ children }: { children: React.ReactNode }) {
|
|
return children
|
|
}
|