Skip to content

opendataloader-project/opendataloader.org

Repository files navigation

OpenDataLoader.org

This repository hosts the public website and documentation for OpenDataLoader. It is a Turborepo workspace whose only app today is apps/v1, a Next.js 16 site that renders marketing pages plus the Fumadocs-powered docs experience under /docs.

What lives where

Path Purpose
apps/v1/src/app Next.js App Router routes such as /, /contact, /docs, /showcase, API routes, and global layout assets.
apps/v1/content/docs Source-of-truth MDX pages that Fumadocs ingests. Each file maps directly to /docs/:slug.
apps/v1/public Static assets. Use public/figures for images referenced inside docs.
apps/v1/source.config.ts Fumadocs defineDocs config that points at content/docs.
turbo.json, pnpm-workspace.yaml Workspace orchestration for builds, linting, and dependency sharing.

Developer onboarding (core engineers)

  • Prerequisites
    • Node.js ≥ 18 (match .nvmrc if present) and pnpm@9 (corepack enable pnpm keeps versions consistent).
    • Optional: turbo installed globally for faster local runs (pnpm add -g turbo).
  • Install once
    pnpm install
  • Daily commands
    • pnpm dev --filter v1 — runs the Next.js dev server with the docs, marketing pages, and API routes.
    • pnpm build --filter v1 — production build. CI runs pnpm build from the repo root which fans out via Turborepo.
    • pnpm lint --filter v1 and pnpm format — keep ESLint + Prettier happy before opening PRs.
  • Environment variables
    • Only one secret is required locally today: RESEND_API_KEY for the /api/contact route (apps/v1/src/app/api/contact/route.ts). Without it, contact form submissions will fail; guard the UI or disable the route while developing if you do not have a key.
    • Add any new secrets to .env.local and document them in this README under this section.
  • Testing checklist before opening a PR
    • Run pnpm dev --filter v1 and exercise the pages you touched, especially /docs, /contact, and /showcase.
    • Run pnpm lint --filter v1.
    • If you changed MDX or assets, confirm images resolve from apps/v1/public.

Fumadocs authoring (non‑developer managers)

You only need basic Markdown knowledge to keep docs up to date. Everything lives under apps/v1/content/docs.

  • Add or edit a page
    1. Duplicate an existing file (for example apps/v1/content/docs/quick-start-python.mdx) and rename it with a URL-friendly slug (e.g., pricing.mdx/docs/pricing).
    2. Update the frontmatter block at the top:
      ---
      title: Short headline shown in the sidebar
      description: One sentence summary used in SEO and cards
      ---
    3. Write content in Markdown. MDX lets you embed React components such as <Cards> or <Callout> if needed; existing examples in the folder provide copy‑and‑paste starter blocks.
  • Keep the navigation in sync
    • apps/v1/content/docs/meta.json controls sidebar groupings. Add the new slug (without .mdx) in the right section. Lines starting with ---Heading--- are visual dividers, not pages.
    • The order of entries in meta.json is the order shown in the sidebar.
  • Reuse assets
    • Place screenshots or diagrams in apps/v1/public/figures and reference them with root-relative paths, for example ![Diagram](/figures/architecture.png). The site deploy pipeline automatically fingerprints and serves them.
  • Linking tips
    • Prefer relative links such as [JSON schema](./json-schema); Fumadocs resolves them automatically (apps/v1/src/app/docs/[[...slug]]/page.tsx wires this up via createRelativeLink).
    • External links should include https:// and will open in a new tab by default.
  • Preview options
    • If you are comfortable running commands: pnpm dev --filter v1, then open http://localhost:3000/docs.
    • Otherwise, edit the MDX file on GitHub, create a pull request, and use the autogenerated Vercel preview link to review the rendered page before merging.
  • Publishing checklist
    • Confirm the page title and description are populated.
    • Scan the sidebar to be sure the new page is listed once.
    • Check that any code blocks declare their language (bash, ts) for syntax highlighting.
    • Ask an engineer to merge once the preview looks good; deployments are automated via the main branch.