Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/apursley2012/y2k-webring/llms.txt

Use this file to discover all available pages before exploring further.

This guide walks you through cloning Y2K Webring, serving it locally, and making it your own. The repository ships as a pre-built static site — the compiled JS/CSS bundles and pre-rendered HTML files are already present, so you can open it in a browser immediately after cloning without running a build step.
The published repository contains compiled output only (no package.json). If you want to modify component source files and rebuild, you will need to set up your own Vite + React project using the compiled files as a reference, then run the standard Vite build commands described at the end of this page.

Prerequisites

Before you begin, make sure you have the following installed:
  • Git — to clone the repository.
  • A static file server — any tool that can serve a folder of HTML/JS/CSS files locally (for example, the serve npm package, Python’s http.server, or VS Code’s Live Server extension).

Installation

1

Clone the repository

Clone Y2K Webring from GitHub and move into the project directory:
git clone https://github.com/apursley2012/y2k-webring.git && cd y2k-webring
2

Serve the static output

Open the pre-built site with any local static file server. For example, using the serve package:
npx serve .
Or using Python’s built-in HTTP server:
python3 -m http.server 5173
Then open http://localhost:5173 in your browser. Because the router uses hash-based URLs, all navigation works without any server configuration.
3

Personalize content

Edit data/portfolioData.js to replace the sample data with your own projects, skills, writing, and contact links. This is the only file you need to change for a fully personalized portfolio. See Customize Data for the full schema.
4

Deploy

Upload the repository contents (as-is, after editing portfolioData.js) to any static file host. No build step is needed because the bundles are already compiled. See the Deploying section below for host-specific instructions.

If You Are Building from Source

If you have a copy of the original Vite source project (with package.json present), the standard development workflow applies:
1

Install dependencies

Install the project dependencies using your preferred package manager:
npm install
2

Start the development server

Launch the Vite dev server:
npm run dev
Vite will print a local URL — open http://localhost:5173 in your browser to see the portfolio. The server supports hot module replacement (HMR), so changes to component and data files are reflected instantly without a full reload.
3

Build for production

When you are ready to publish, compile an optimized static bundle:
npm run build
Vite writes the output to the dist/ directory. The build includes tree-shaken JS modules, the compiled main.css, and all pre-rendered HTML pages from pages/.
4

Preview the production build

Before deploying, verify the production build locally with Vite’s built-in preview server:
npm run preview
This serves the contents of dist/ on a local port so you can confirm routing and assets behave exactly as they will in production.

Personalizing Your Portfolio

All portfolio content is centralized in a single file: data/portfolioData.js. You do not need to touch any component code to replace the placeholder content with your own — just edit this file. The module exports six named objects:
ExportVariableContents
SdevInfoYour name, tagline, bio, current status, stats, and social links
PprojectsArray of project cards (name, stack, status, description, URLs)
askillsObject of skill categories, each containing rated skill entries
WwritingPostsArray of blog/writing post entries with tags and full content
CcaseStudiesArray of detailed case study objects
GguestbookArray of guestbook entry objects
Here is the top-level structure of the file so you know exactly what to edit:
// data/portfolioData.js

// ── Dev info (S) ──────────────────────────────────────────────
const devInfo = {
  devName: "ALEX.EXE",
  tagline: "No actual spells, just suspiciously organized files.",
  bio: "Full-stack developer weaving code into the digital ether...",
  status: {
    building: "A haunted React component",
    reading: "Documentation from 2014",
    debugging: "Reality (and CSS grids)",
  },
  guestbookCount: 1337,
  stats: {
    location: "The Pacific Northwest (probably raining)",
    pronouns: "they/them",
    obsessedWith: "mechanical keyboards, obscure CSS properties, cold brew",
    previously: "nursing student / healthcare / retail / merchandiser",
    peeves: "off-center buttons, fake enthusiasm, inconsistent branding",
  },
  socials: [
    { name: "GitHub",   url: "#", icon: "github"   },
    { name: "LinkedIn", url: "#", icon: "linkedin" },
    { name: "Email",    url: "#", icon: "mail"     },
    { name: "RSS",      url: "#", icon: "rss"      },
  ],
};

// ── Projects (P) ──────────────────────────────────────────────
const projects = [
  {
    id: "proj-1",
    name: "Grimoire.js",
    stack: ["React", "TypeScript", "WebGL"],
    status: "✦ shipped",
    description: "A digital spellbook for managing code snippets...",
    dataSource: "live",   // "live" | "mocked" | "sample"
    demoUrl: "#",
    sourceUrl: "#",
    readmeUrl: "#",
  },
  // ...more projects
];

// ── Skills (a) ────────────────────────────────────────────────
const skills = {
  Languages: [
    { name: "TypeScript", level: 5, note: "5 years of strict typing" },
    // ...
  ],
  Frontend: [ /* ... */ ],
  "Backend & Data": [ /* ... */ ],
  Tooling: [ /* ... */ ],
  "Design Sensibilities": [ /* ... */ ],
};

// ── Writing posts (W) ─────────────────────────────────────────
const writingPosts = [
  {
    id: "post-1",
    title: "Why I Still Use Chunky Borders in 2026",
    date: "2026-05-13",
    excerpt: "A defense of the 2px solid border...",
    tags: ["Design", "Reflection"],
    content: "Full post body as a plain string...",
  },
  // ...
];

// ── Case studies (C) ──────────────────────────────────────────
const caseStudies = [
  {
    id: "cs-1",
    title: "Neon_Bazaar: Reimagining E-commerce",
    setup: "...",
    problem: "...",
    investigation: "...",
    designChoices: "...",
    buildChoices: "...",
    bugs: [
      { name: "Stripe Webhook Duplication", hp: 45 },
      { name: "Framer Motion Memory Leak on Mobile", hp: 80 },
    ],
    result: "...",
    nextTime: "...",
  },
];

// ── Guestbook (G) ─────────────────────────────────────────────
const guestbook = [
  {
    id: 1,
    name: "Recruiter_Sarah",
    date: "2026-05-20",
    text: "Love the aesthetic!...",
    color: "text-y2k-lime",  // "text-y2k-lime" | "text-y2k-cyan" | "text-y2k-magenta"
  },
  // ...
];

export { caseStudies as C, guestbook as G, projects as P, devInfo as S, writingPosts as W, skills };
The icon field in devInfo.socials must be one of "github", "linkedin", "mail", or "rss" — these are the four icons imported from lucide-react in the RightWebring component.

Deploying

Y2K Webring uses hash-based routing (HashRouter). Every URL takes the form https://your-domain.com/#/projects, so the server always serves index.html regardless of the path — no server-side rewrite rules or _redirects files are needed. This makes it compatible with any static file host. Because the repository ships as pre-compiled output, you can deploy the repository root directly — no build step is required. Upload the repo contents to your host of choice:
  • GitHub Pages — push the repository to GitHub and configure Pages to serve from the repository root (or the main branch). The index.html entry point and all pre-compiled assets will be served as-is.
  • Netlify — drag-and-drop the repository folder in the Netlify UI, or connect the repo and leave the build command blank with the publish directory set to . (the root).
  • Vercel — import the repo and set the framework to “Other” (not Vite, since there is no package.json). Set the output directory to . so Vercel serves the repo root directly.
For the full portfolioData.js content schema — including all field types, optional properties, and the dataSource enum used on project cards — see Customize Data.

Build docs developers (and LLMs) love