Thanks for your interest in improving PageLM! This guide explains how to propose changes while keeping the project healthy and predictable.
- Discuss first: Open an issue or join the existing discussion before large changes. This reduces duplicate work and ensures the direction aligns with the project roadmap.
- Set up locally: Run
npm installat the repository root. The frontend lives infrontend/, the backend inbackend/. - Node version: Use the version declared in
package.json("engines": { "node": ">=21.18.0" }). Managing versions withnvm/fnmhelps.
- Branching: Create a topic branch from
mainnamed<user>/<feature>or<user>/<bugfix>. - Code style:
- TypeScript/JavaScript should pass
npm run build(root and frontend). - Keep files ASCII unless they already use other encodings.
- Favor small, focused commits with meaningful messages.
- TypeScript/JavaScript should pass
- Tests & checks:
- Backend:
npm run build(root). - Frontend:
npm run buildinfrontend/. - Add targeted tests or scripts when introducing behaviour that can regress.
- Backend:
- Documentation: Update README, inline comments, or other docs when behavior or APIs change.
- Reference related issues.
- Provide a concise summary of the change and any follow-up work.
- Note manual testing steps and results.
- Keep PRs atomic; independent changes should be separate PRs.
- Reviews focus on correctness, clarity, security, performance, and maintainability.
- Address feedback promptly; push follow-up commits instead of force-pushing so history is clear.
- Nullure (morven) is the final reviewer for architectural or governance-impacting changes.
Thank you for helping build a great learning companion! 🎓