Repository Guidelines

Project Structure & Module Organization

Core configuration sits in _config.yml; shared data such as navigation and resumes lives in _data/. Topic folders like programming/ and technology/ hold nested _posts/; draft in _drafts/ before moving files into the matching _posts/. Custom JavaScript lives in _js/src/ and compiles into assets/js/, while static media stays under assets/. The Hydejack theme source lives in #jekyll-theme-hydejack/—treat it as read-only unless you sync upstream. Deployment template config/nginx.conf.erb supports production servers. _site/ is generated output and should never be edited manually.

Build, Test, and Development Commands

Install dependencies with bundle install and npm install. Run npm run dev to launch webpack watchers and bundle exec jekyll serve --host 0.0.0.0 --port 4000 for local preview. For release checks execute npm run build to emit JS/CSS bundles, then bundle exec jekyll build to render _site/. Clean bundles with npm run clean, and regenerate résumé YAML via npm run resume after editing _data/resume.json.

Coding Style & Naming Conventions

JavaScript follows Prettier defaults—run npm run format before committing to normalize spacing and imports. Keep module filenames kebab-cased (for example, scroll-restore.js) and prefer named exports for shared utilities. Markdown posts start with concise YAML front matter, use lowercase hyphenated filenames like 2024-06-15-new-post.md, and wrap prose near 100 characters for readability. When extending the theme, mirror Hydejack’s SCSS partial pattern inside #jekyll-theme-hydejack/_sass/.

Testing Guidelines

There is no automated suite (npm test is a stub), so rely on build validation and manual QA. Always run bundle exec jekyll build before pushing to catch Liquid or front matter errors, then spot-check _site/. Use bundle exec jekyll doctor to surface broken links, and confirm webpack exits cleanly whenever JavaScript changes ship.

Commit & Pull Request Guidelines

Keep commits focused and use short, capitalized summaries consistent with history (Added music, Update resume info). Reference related issues in the body when applicable, and avoid mixing content edits with theme refactors. Pull requests should outline motivation, list verification commands (e.g., npm run build, bundle exec jekyll build), and include screenshots or recordings for visual changes. Mention updates to deployment assets such as config/nginx.conf.erb so reviewers can validate infrastructure impacts.