Thanks for your interest in contributing! This guide will help you get started.
- Node.js 18+
- npm or yarn
- Git
# Fork and clone the repo
git clone https://github.com/<your-username>/fetch-smartly.git
cd fetch-smartly
# Install dependencies
npm install
# Run tests to verify setup
npm test
# Build the project
npm run build
# Type check
npm run lintUse the Bug Report template. Include:
- Package version and Node.js version
- Steps to reproduce
- Expected vs actual behavior
Use the Feature Request template.
- Check existing issues — Look for open issues or create one before starting.
- Fork the repo and create a branch from
main:git checkout -b feat/your-feature # or git checkout -b fix/your-bugfix - Write your code following the guidelines below.
- Write or update tests for your changes.
- Run checks before committing:
npm run lint npm test npm run build - Commit with a clear message (see Commit Convention).
- Push and open a Pull Request.
| Type | Format | Example |
|---|---|---|
| Feature | feat/short-description |
feat/add-new-adapter |
| Bug fix | fix/short-description |
fix/edge-case-error |
| Docs | docs/short-description |
docs/update-api-guide |
| Refactor | refactor/short-description |
refactor/simplify-core |
Use Conventional Commits:
feat: add new feature
fix: correct bug in module
docs: update configuration examples
test: add tests for edge case
refactor: simplify internal logic
chore: update dependencies
- TypeScript — All source code in TypeScript. Maintain strict typing.
- Tests — Write tests using Vitest. Aim for coverage on new code.
- No breaking changes without discussion — Open an issue first.
- Keep it focused — One PR = one concern.
- Document public APIs — Add JSDoc comments for exported functions and types.
src/ # Source code (TypeScript)
dist/ # Build output (do not edit)
docs/ # VitePress documentation site
tests/ # Test files
- Fill out the PR template completely.
- Ensure all checks pass (tests, types, build).
- Link the related issue (e.g.,
Closes #12). - Request a review from a maintainer.
- Address review feedback with new commits (don't force-push).
- A maintainer will merge once approved.
Look for issues labeled good first issue.
By contributing, you agree to follow our Code of Conduct.
By contributing, you agree that your contributions will be licensed under the MIT License.
Open a Question issue. We're happy to help!