Thanks for helping improve NitroCraft. We aim to keep contributions practical, secure, and easy to review.
- Check for existing issues or pull requests before opening a new one.
- Keep changes focused and scoped to one problem.
- If you plan a larger change, open an issue first to align approach.
- Use Node
24(.nvmrc/.node-version) and pnpm10.22.0.
- Use a clear title and describe expected vs actual behavior.
- Include reproduction steps, relevant logs, and environment details.
- Share version info (
node, OS, runtime context such as Docker/Pterodactyl). - If applicable, include request URL examples and response codes.
- Keep PRs small and reviewable.
- Explain what changed, why it changed, and any risk/compatibility impact.
- Update docs/config examples when behavior or configuration changes.
- Follow existing project style and file organization.
- Prefer root-cause fixes over temporary patches.
- Contributor Minecraft avatars can be added to the homepage jumbotron sample list.
- Pinned contributor entries use
data-pinned="true"and are always kept visible in the jumbotron, including on mobile. - If you want to be added, include your Minecraft username/UUID in your PR notes.
- Follow the existing style of the repository.
- Keep code readable and consistent.
- Prefer clear naming and simple, maintainable implementations.
- Add comments only when behavior is non-obvious.
- Add tests for new behavior when feasible (
test/unit/*.test.ts). - If fixing a bug, add a test that would have caught it.
- Run tests before opening a PR:
pnpm test
- Ensure your change does not reduce overall reliability.
- Never commit secrets (
.env, API keys, passwords). - Keep dependency and security changes intentional and documented.
- Call out operational changes (cache, retention, Redis, routing, headers) in PR notes.
- Code is clean and follows style rules.
- Tests/docs updated where needed.
- PR description clearly explains impact.
- Ready for maintainers to review and merge.