Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
169 lines (111 loc) · 4.47 KB

CONTRIBUTING.md

File metadata and controls

169 lines (111 loc) · 4.47 KB

Contributing to VuReact Core

Thanks for helping improve VuReact Core. This guide focuses on the workflow contributors should follow in this repository.

Before You Start

Make sure your local environment matches the current workspace requirements:

  • Node.js >= 19.0.0
  • pnpm 10+ recommended
  • Git

This repository is a pnpm workspace with two main packages:

  • @vureact/compiler-core
  • @vureact/runtime-core

Please also review the Code of Conduct and note that contributions are released under the MIT License.

Choose the Right Collaboration Channel

Start with discussion before implementation when the change is significant.

Open or join an Issue or Discussion before writing code for:

  • new features
  • breaking changes
  • architecture changes
  • large refactors

Use the existing GitHub templates and channels:

Small typo fixes and straightforward documentation corrections can go directly to a Pull Request.

Local Setup

  1. Fork the repository on GitHub.

  2. Clone your fork and enter the workspace:

    git clone https://github.com/YOUR_USERNAME/core.git
cd core

  3. Install dependencies:

    pnpm install

  4. Build the packages you plan to touch:

    pnpm build:compiler-core
pnpm build:runtime-core

  5. Create a branch from the latest upstream default branch.

Make Changes

Keep changes focused and easy to review.

  • Follow the existing code style and project structure.
  • Add or update documentation when behavior changes.
  • Add or update tests when your change affects behavior.
  • Avoid mixing unrelated refactors into the same Pull Request.

If your work touches both packages, describe the relationship clearly in your PR so reviewers can validate the integration path.

Validate Changes

Run the checks that match the area you changed. Prefer targeted verification with a clear scope over vague claims like "all tests passed".

Formatting

Run Prettier checks from the workspace root:

pnpm format:check

runtime-core

Use the root scripts for the affected area:

pnpm test:adapter-hooks
pnpm test:adapter-utils
pnpm test:adapter-components

Run the relevant package build as well:

pnpm build:runtime-core

compiler-core

At minimum, run the package build:

pnpm build:compiler-core

If your change affects parsing, transforms, code generation, or watch/build behavior, also run the most relevant area-specific verification available in that part of the package. The repository does not currently expose one single top-level automated test command for all compiler-core scenarios, so document exactly what you ran in the PR.

Commit and Open a PR

Use clear commits. Conventional Commits are recommended:

<type>[optional scope]: <description>

Common types used in this repository:

  • feat
  • fix
  • docs
  • refactor
  • test
  • build
  • ci
  • chore

Examples:

feat(compiler-core): improve scoped style transform output
fix(runtime-core): correct adapter hook update timing
docs: rewrite contribution guide

Before opening a Pull Request:

  • rebase or merge from the latest upstream default branch as needed
  • make sure the relevant build and verification steps pass locally
  • update docs when user-facing behavior changes

When opening the PR, follow the existing template:

Your PR description should include:

  • the related issue, if any
  • the affected package or packages
  • the exact validation you ran
  • screenshots only when they help explain the change

Review Expectations

Reviewers may ask for clarification, narrower scope, or additional validation. That is part of keeping the project maintainable.

To help reviews move quickly:

  • keep PRs focused
  • respond to feedback with concrete updates
  • call out tradeoffs or known follow-up work
  • avoid force-pushing away context unless cleanup is necessary

If ownership is unclear, the repository's CODEOWNERS file helps route reviews.