This repository is the source for the OpenPrinting website. It is a Next.js App Router site that statically exports to GitHub Pages.
When reviewing changes in this repo, optimize for:
- behavioral regressions in page generation, routing, and content loading
- breakage specific to static export and GitHub Pages deployment
- content/rendering issues in Markdown-driven pages
- accidental edits to generated artifacts or vendored output
app/: route handlers and page entry pointscomponents/: shared UI, Markdown rendering, navigation, search UIcontents/: source content in Markdowndata/: structured data for authors, GSOC/GSOD pages, summarieslib/: shared helpers for content loading, image path handling, search runtimescripts/search/: build-time search index generationpublic/: static assets and generated search index output
Treat these as source files:
app/**components/**contents/**data/**lib/**scripts/**- config files such as
package.json,tsconfig.json,next.config.ts,eslint.config.mjs
Treat these as generated or build output and review them only when the change explicitly requires regeneration:
.next/out/public/search/static-index.jsonnode_modules/
If a PR changes generated output without changing the inputs that produce it, call that out.
- Static export is enabled in
next.config.ts.output: "export"means features requiring a server runtime are risky by default. - Production builds compute
basePathandassetPrefixdynamically viaconfig/site.config.ts. Absolute links, image paths, and asset references must continue to work correctly under this generated prefix. Do not hardcode strings like/openprinting.github.io. - Search index generation runs in
prebuildviatsx scripts/search/build-index.ts. Changes affecting content extraction, slugs, URLs, or searchable text often require regeneratingpublic/search/static-index.json. - A large part of the site is Markdown-driven. Review content pipeline changes for frontmatter assumptions, slug handling, excerpt/title sanitization, and image resolution.
- This repo uses Yarn as the expected package manager. Flag changes that introduce package-manager drift or inconsistent lockfile/package-manager usage unless the migration is intentional.
- Canonical URLs have no trailing slash:
/some-page.next.config.tssetstrailingSlash: false, so the export writesout/some-page.htmland GitHub Pages serves it directly for/some-page. - Write internal links, canonical URLs, sitemap entries and RSS
<link>s in that form. Two deliberate exceptions:/cups/(separate CUPS Pages site) and RSS<guid>s, which keep their historical trailing slash because they are item identities -- changing them makes feed readers re-announce old articles. scripts/generate-trailing-slash-aliases.tswritesout/some-page/index.htmlredirect stubs after the export so old inbound links ending in/keep working.yarn verify:urlschecks these invariants and gates both CI and deployment.
- Single Source of Truth: All deployment-specific values, such as GitHub organization / repository names, base paths, and external URLs (e.g., Giscus configs, CI pipelines), are centralized in
config/site.config.ts. - Migration Guide: When migrating the repository or deploying to a new location, update
config/site.config.ts. Always importsiteConfigfrom"@/config/site.config"rather than hardcoding.
- Check that route params map to the right content directories.
- Watch for slug mismatches between file names, generated URLs, and redirects.
- For dynamic routes like
app/[...slug],app/documentation/[doc], andapp/projects/[project], verify not-found and redirect behavior still makes sense for static export.
- Flag use of features that depend on request-time server execution unless the repo already supports them safely.
- Be suspicious of changes that assume root-relative assets without considering the production
basePath. - For images and links, prefer helpers already used by the repo such as
getImageSrc. - Check that asset
srcvalues are valid for both local development and production export. A change that appears to work locally but breaks under the production prefix should be treated as a bug.
- UI changes should follow the current visual theme of the site rather than introducing a disconnected style.
- Verify layouts remain responsive across common mobile and desktop widths.
- Confirm UI changes remain compatible with both light mode and dark mode, including text contrast, borders, icons, and code/content surfaces.
- Review changes to
components/markdown-renderer.tsxcarefully. It usesrehype-raw, so rendering changes can have broad effects on embedded HTML in content. - Confirm frontmatter fields remain optional where the content corpus is inconsistent.
- Check that teaser images, author metadata, and reading time logic still degrade gracefully for older posts.
- Review
scripts/search/*,lib/search/*, andpublic/search/static-index.jsontogether. - If URL generation or content extraction changes, verify the search index schema and document URLs remain consistent with the app routes.
- When reviewing bulk Markdown edits, prioritize broken links, malformed frontmatter, invalid image paths, and dates/slugs that affect sorting or routing.
- For post metadata, note that date parsing affects ordering in helpers such as
lib/get-latest-posts.ts.
Use the smallest relevant validation first, then escalate to a full build for routing/content pipeline changes.
yarn lint
yarn buildWhat each command validates here:
yarn lint: code quality and some framework-level issuesyarn build: static export viability and search index generation
There does not appear to be a dedicated test suite in this repo. If you cannot run a command, say so explicitly in the review.
When reviewing a change, lead with findings, not a summary. Prioritize:
- broken routes or static export regressions
- asset path and
basePathmistakes - content parsing or Markdown rendering regressions
- generated-file churn without corresponding source changes
- missing validation for risky changes
If no issues are found, say that explicitly and mention any residual risk, especially when a full npm run build was not run.
- Avoid editing generated directories unless the task explicitly requires regeneration.
- Do not overwrite user changes in generated artifacts to "clean up" the diff.
- If content or search behavior changes, mention whether
public/search/static-index.jsonshould be regenerated. - Keep new code compatible with static export unless the task clearly changes deployment assumptions.