Thank you for your interest in contributing to schema-dsl! This document describes how to participate in this project.
We welcome all types of contributions, including:
- Bug reports: Found a bug? Please submit an issue.
- Feature requests: Have an idea? Open a feature request.
- Bug fixes: Submit a Pull Request to fix a confirmed bug.
- New features: Implement a new feature after discussion.
- Documentation: Improve or translate documentation.
- Tests: Add test cases to improve coverage.
- Node.js >= 18.0.0
- pnpm >= 8.0.0 (recommended package manager)
# Clone the repository
git clone https://github.com/vextjs/schema-dsl.git
cd schema-dsl
# Install dependencies
pnpm install
# Build the project
npm run build
# Run tests
npm testnpm run build # Build production output (CJS + ESM + types)
npm test # Run all tests
npm run typecheck # TypeScript type checking
npm run lint # Run ESLint
npm run test:version # Verify version consistency| Branch | Purpose |
|---|---|
main |
Production-ready stable code |
develop |
Integration branch for features |
feat/* |
New feature development |
fix/* |
Bug fixes |
chore/* |
Tooling, dependencies, CI |
docs/* |
Documentation updates |
Always branch off from develop for new work.
git checkout develop
git pull origin develop
git checkout -b feat/your-feature-nameBefore submitting a PR, ensure:
- Tests pass: All existing and new tests pass.
- Coverage: Test coverage remains >= 80%.
- Linting: No ESLint errors (warnings are acceptable).
- Type checking: No TypeScript errors.
- Documentation: Updated if the change affects public API.
- CHANGELOG: Add an entry if applicable.
npm run typecheck
npm run lint
npm testTarget your PR at the develop branch (not main).
We follow the Conventional Commits specification:
<type>(<scope>): <description>
[optional body]
[optional footer(s)]
Types:
| Type | When to Use |
|---|---|
feat |
A new feature |
fix |
A bug fix |
docs |
Documentation only changes |
style |
Formatting, no logic change |
refactor |
Code refactoring, no feature/fix |
perf |
Performance improvement |
test |
Adding or updating tests |
build |
Changes to build system or dependencies |
chore |
Other maintenance tasks |
ci |
CI/CD configuration |
Examples:
feat(parser): add support for union type shorthand
fix(validator): correct min-length error message for empty strings
docs(readme): update installation instructions
test(core): add edge cases for conditional validation
This project uses ESLint and Prettier for code consistency.
# Check for linting errors
npm run lint
# Format code (if configured)
npx prettier --write src/Key guidelines:
- Use TypeScript strict mode features
- Prefer
constandletovervar - Use descriptive variable names
- Add JSDoc comments for all public APIs
- Avoid
anytype — use proper types or generics - Handle errors explicitly
We use Vitest as the test framework.
# Run all tests
npm test
# Run tests in watch mode
npx vitest --watch
# Run a specific test file
npx vitest run test/unit/your-test.test.ts
# Check coverage
npx vitest run --coverageRequirements:
- Coverage must remain >= 80% (tracked by Vitest)
- Each new feature must include unit tests
- Each bug fix must include a regression test
- Tests should be deterministic and independent
test/
unit/
core/ # Core module tests
parser/ # Parser tests
adapters/ # Adapter tests
exporters/ # Exporter tests
Releases are managed by maintainers. The process follows:
- Update
package.jsonandplugin.jsonversion numbers. - Add changelog entry.
- Run full verification:
npm run typecheck && npm run lint && npm test && npm run build. - Commit:
git commit -m "release: vX.Y.Z - description". - Tag:
git tag vX.Y.Z. - Push:
git push && git push origin vX.Y.Z. - Create a GitHub Release from the tag.
- Open an Issue for bugs or feature requests.
- Email: rockyshi1993@gmail.com
By contributing, you agree that your contributions will be licensed under the same MIT License as the project.