Portfolio

Portfolio Website to visually show off my work in my career and free time.
https://nickhs.dev/

View Website · Report Bug · Request Feature

Table of Contents

1. About The Project
   • Built With
2. Getting Started
   • Installation
3. Usage
4. Available Scripts
5. Testing
6. Project Maintenance
7. Contributing
8. Releases
9. Deployment
10. License

About The Project

Built With

Getting Started

Prerequisites

• Node.js version 22 or higher
• Yarn package manager (version 4 or higher)
• (Optional) nvm for Node version management

Installation

1. Clone the repo

   git clone https://github.com/CampAsAChamp/portfolio.git

2. Navigate into the repo

   cd portfolio

3. (Optional) If using nvm, install and use the correct Node version

   nvm install
   nvm use

   This will automatically use the Node version specified in .nvmrc
4. Install dependencies

   yarn install

   Or simply:

   yarn

5. Start the development server

   yarn start

6. Open your web browser to localhost:5173

Usage

1. View the site live at https://nickhs.dev/

Available Scripts

Development

• yarn start or yarn dev - Start development server on localhost:5173
• yarn build - Create production build in build/ directory
• yarn preview - Preview production build locally on localhost:4173

Testing

• yarn test - Run unit tests once
• yarn test:watch - Run unit tests in watch mode
• yarn test:ui - Open interactive Vitest UI
• yarn test:coverage - Generate test coverage report
• yarn test:e2e - Run Playwright E2E tests
• yarn test:e2e:ui - Open interactive Playwright UI
• yarn test:e2e:headed - Run E2E tests with visible browser
• yarn test:lighthouse - Run Lighthouse CI audits (builds and audits production site)
• yarn test:all - Run all tests (unit + Lighthouse + E2E)

Code Quality

• yarn lint - Run all linters (ESLint, TypeScript, Stylelint, Prettier)
• yarn lint:fix - Auto-fix linting issues and format code
• yarn lint:eslint - Run ESLint only
• yarn lint:eslint:fix - Auto-fix ESLint issues
• yarn lint:types - Run TypeScript type checking
• yarn lint:css - Run Stylelint on CSS files
• yarn lint:css:fix - Auto-fix CSS linting issues

Analysis

• yarn analyze - Analyze bundle size with source-map-explorer

Testing

This project includes comprehensive automated testing to catch regressions and ensure quality.

Unit Tests

Unit tests verify component rendering and behavior using Vitest and React Testing Library.

Run all unit tests once:

yarn test

Run tests in watch mode (useful during development):

yarn test:watch

Open the Vitest UI for an interactive testing experience:

yarn test:ui

Generate test coverage report:

yarn test:coverage

E2E Tests

End-to-end tests verify the application works correctly in real browsers using Playwright.

Run all E2E tests:

yarn test:e2e

Run E2E tests with interactive UI:

yarn test:e2e:ui

Run E2E tests with browser visible (headed mode):

yarn test:e2e:headed

Test Coverage:

• Functional tests verify user interactions and navigation
• Visual regression tests catch unintended UI changes
• Tests run against 5 browser configurations:
  • Desktop: Chrome, Firefox, Safari
  • Mobile: Chrome (Pixel 5), Safari (iPhone 12)

Lighthouse Performance Audits

Lighthouse CI verifies the portfolio maintains high performance, accessibility, best practices, and SEO standards using Google's official Lighthouse tooling.

Run Lighthouse audits locally:

yarn test:lighthouse          # Runs desktop tests (default)
yarn test:lighthouse:desktop  # Explicitly run desktop tests
yarn test:lighthouse:mobile   # Run mobile tests with device emulation
yarn test:lighthouse:both     # Run both desktop and mobile tests

This command builds the production site and runs a Lighthouse audit to verify performance and quality standards.

Monitored Metrics:

• Performance (threshold: 85+): Load times, Core Web Vitals (LCP, CLS, FID), bundle optimization
• Accessibility (threshold: 90+): ARIA labels, keyboard navigation, color contrast, semantic HTML
• Best Practices (threshold: 90+): HTTPS, console errors, deprecated APIs, security
• SEO (threshold: 90+): Meta tags, mobile-friendliness, structured data

Configuration: Lighthouse settings are defined in:

• .lighthouserc.desktop.json - Desktop preset (no throttling)
• .lighthouserc.mobile.json - Mobile preset (375x667, 4G throttling, 4x CPU slowdown)

GitHub Integration: Lighthouse CI is configured with a GitHub token to provide:

• ✅ Status checks on commits showing pass/fail for each category
• 💬 PR comments with score comparisons when changes affect performance
• 📊 Integration with GitHub's checks interface

Local Development: To run Lighthouse locally without token warnings:

1. Copy .env.example to .env.local: cp .env.example .env.local
2. Add your GitHub token to .env.local
3. The token will be automatically loaded when running yarn test:lighthouse

Run All Tests

Run unit tests, Lighthouse audits, and E2E tests:

yarn test:all

This command runs all three test suites in sequence: unit tests with Vitest, Lighthouse performance audits, and E2E tests with Playwright. Tests are ordered from fastest to slowest for quicker feedback.

Continuous Integration

The CI pipeline runs automatically on every push and pull request via GitHub Actions (.github/workflows/test.yml):

Test Job:

1. Setup: Install Node.js 22 and dependencies
2. Lint: Run ESLint, Stylelint, and TypeScript type checking
3. Test: Run unit tests with Vitest
4. Build: Create production build
5. Analyze: Check bundle sizes

Lighthouse Job (runs after Test job passes):

1. Build: Create production build
2. Audit: Run desktop Lighthouse audits for performance, accessibility, best practices, and SEO
3. Upload: Save reports to temporary public storage and GitHub artifacts
4. Status: Post GitHub status check with pass/fail results

You can view interactive Lighthouse reports directly from the GitHub Actions run output via the temporary public storage link.

Note: E2E visual regression and functional tests run locally via the pre-push hook but are not part of the CI pipeline to keep build times fast. Pull requests must pass all CI checks before merging.

Test Structure

Tests are located in the tests/ directory, mirroring the structure of src/:

• tests/unit/ - Unit tests with Vitest
  • App.test.tsx - Main app component
  • components/ - Component tests organized by feature
  • hooks/ - Custom hook tests
  • utils/ - Utility function tests
• tests/e2e/ - End-to-end tests with Playwright
  • functional/ - User interaction and navigation tests
  • visual-regression/ - Screenshot comparison tests
• .lighthouserc.desktop.json / .lighthouserc.mobile.json - Lighthouse CI configurations for performance audits
• All tests use TypeScript for type safety
• Focus on catching regressions when updating content or refactoring

Project Maintenance

Automated Dependency Updates

This project uses Dependabot to automatically keep dependencies up to date:

• Runs weekly on Mondays at 9:00 AM PST
• Creates grouped pull requests for related dependencies:
  • React ecosystem packages
  • Testing libraries (Vitest, Playwright, Testing Library)
  • Linting tools (ESLint, TypeScript, Prettier, Stylelint)
  • Build tools (Vite, Rollup)
• Also updates GitHub Actions weekly
• Maximum of 5 open dependency PRs at a time
• All PRs follow conventional commit format

Configuration can be found in .github/dependabot.yml.

Security

For information about reporting security vulnerabilities, see SECURITY.md.

Changelog

All notable changes are automatically documented in CHANGELOG.md by semantic-release. The changelog is generated from conventional commit messages and should not be manually edited. See Releases for more information.

Contributing

This project follows conventional commit standards to maintain a clean and readable git history.

Commit Message Format

All commit messages must follow the Conventional Commits specification:

<type>(<optional-scope>): <subject>

Example commits:

feat: add dark mode toggle
fix: resolve mobile navigation bug
docs: update README with setup instructions
chore: update dependencies
refactor(auth): simplify login logic
test: add unit tests for utils
style: format code with prettier
perf: optimize image loading

Commit Types

• feat: A new feature
• fix: A bug fix
• docs: Documentation changes
• style: Code style changes (formatting, missing semicolons, etc.)
• refactor: Code changes that neither fix bugs nor add features
• perf: Performance improvements
• test: Adding or updating tests
• build: Changes to build system or dependencies
• ci: Changes to CI configuration files and scripts
• chore: Other changes that don't modify src or test files
• revert: Reverts a previous commit

Validation

Commit messages are automatically validated using commitlint:

• The commit-msg hook runs on every commit
• Invalid commit messages will be rejected
• You'll see an error message explaining what's wrong

To manually validate a commit message:

echo "feat: your message" | yarn commitlint

Pre-commit Hooks

This project uses Husky to enforce quality standards:

• pre-commit: Runs lint-staged which formats and lints only staged files:
  • ESLint auto-fixes JavaScript/TypeScript issues
  • Prettier formats code
  • Stylelint fixes CSS issues
• commit-msg: Validates commit message format with commitlint (rejects invalid commits)
• pre-push: Runs yarn test:all (unit tests, Lighthouse audits, and E2E tests) before pushing

Note: If tests fail during pre-push, the push will be blocked. Ensure all tests pass locally before pushing.

Node Version: All tests require Node.js version 22 or higher (specified in .nvmrc). If you use nvm, run nvm use to switch to the correct version.

Deployment

This project automatically deploys to Cloudflare Pages.

Automatic Deployment

Cloudflare Pages automatically deploys your site whenever you push to the repository:

1. Make your changes and commit them (following conventional commit format):

   git add .
   git commit -m "feat: your feature description"

2. Push to the main branch:

   git push origin main

3. Cloudflare Pages will automatically:

   • Detect the changes
   • Install dependencies
   • Build the project with yarn build
   • Deploy to production

4. View deployment status and logs in your Cloudflare Pages dashboard

5. Your site will be live at https://nickhs.dev (or your configured domain)

Cloudflare Pages Configuration

Your Cloudflare Pages project should be configured with:

• Build command: yarn build
• Build output directory: build
• Root directory: / (default)
• Node version: 22 or higher

Custom Domain

The custom domain nickhs.dev is configured in Cloudflare:

1. DNS is managed through Cloudflare
2. SSL/TLS is automatically handled
3. CDN caching and optimization are enabled

To update the domain or DNS settings, visit your Cloudflare dashboard.

Local Development Build

To create a production build locally without deploying:

yarn build

This creates an optimized build in the build folder. To preview the production build locally:

yarn preview

This will serve the production build at localhost:4173.

Notes

• Follow conventional commit format for all commits
• Pre-commit hooks automatically format code and validate commits
• Pre-push hook runs all tests (unit + Lighthouse + E2E) before pushing to remote
• Cloudflare Pages deployments typically complete in 1-2 minutes
• Preview deployments are automatically created for pull requests
• Cloudflare provides automatic HTTPS, CDN, and DDoS protection

Releases

This project uses semantic-release for automated version management and changelog generation.

How It Works

Releases are fully automated based on your commit messages:

1. Commit with conventional format (following the Contributing guidelines)
2. Push to main branch - triggers the CI pipeline
3. After tests pass - the Release workflow automatically:
   • Analyzes commits since the last release
   • Determines the next version number based on commit types
   • Generates release notes from commit messages
   • Updates CHANGELOG.md
   • Creates a GitHub release with notes
   • Tags the release in git

Version Bumping Rules

The version number is automatically determined by commit types:

• Major release (1.0.0 → 2.0.0): Commits with BREAKING CHANGE: in the footer
• Minor release (1.0.0 → 1.1.0): feat: commits
• Patch release (1.0.0 → 1.0.1): fix:, perf:, or revert: commits
• No release: docs:, style:, chore:, refactor:, test:, build:, ci: commits (but they still appear in the changelog)

Example Workflow

# Make changes
git add .

# Commit with conventional format - will trigger patch release
git commit -m "fix: resolve mobile navigation bug"

# Push to main
git push origin main

# GitHub Actions will:
# 1. Run tests (test.yml workflow)
# 2. If tests pass, run release (release.yml workflow)
# 3. Create version 1.0.1 with generated changelog
# 4. Create GitHub release with notes

Important Notes

• DO NOT manually edit CHANGELOG.md - it's automatically generated by semantic-release
• Releases only happen on the main branch after successful test runs
• The release workflow can be viewed at .github/workflows/release.yml
• Release configuration is in .releaserc.json

License

Distributed under the MIT License. See LICENSE for more information.