Skip to content

Latest commit

 

History

History
131 lines (95 loc) · 4.41 KB

CONTRIBUTING.md

File metadata and controls

131 lines (95 loc) · 4.41 KB
Raw

Contribution

Thank you for your interest in improving editable! We are a community-driven project and welcome all forms of contributions, from discussions and documentation to bug fixes and feature enhancements.

Please read this document to help streamline the process and save everyone's valuable time.

Issues

No software is bug-free. So, if you got an issue, follow these steps:

  • Search the issue list for current and old issues.
    • If you find an existing issue, please vote for the issue by adding a "+1" reaction. We use this to help prioritize issues!
  • If none of that is helping, please create an issue.

Reproducing

The best way to help figure out an issue you are having is to produce a minimal reproduction using our CodeSandbox

Development Guide

Initial Setup

pnpm

This repository uses pnpm workspaces, so you should install pnpm as your package manager. See the installation guide.

Clone

git clone https://github.com/editablejs/editable.git

Install & Build

cd editable
pnpm install
pnpm build

Development

Start development server

pnpm dev

Run lint

We use eslint for all code (including typescript code)

All you need to do is:

pnpm lint

Run tests

This command will run all the tests.

pnpm test

Release Guide

This section is for anyone wanting a release. The current release sequence is as follows:

  • Commit your changes:
    • Linting, tests, and build should pass.
  • Open a PR against main and add a changeset.
  • Merge the PR, triggering the bot to create a PR release.
  • Review the final changesets.
  • Merge the PR release, triggering the bot to release the updated packages on npm.

Pull Requests (PRs)

We welcome all contributions.

Reviewing PRs

As a PR submitter, you should reference the issue if there is one, include a short description of what you contributed and, if it is a code change, instructions for how to manually test out the change. This is informally enforced by our PR template. If your PR is reviewed as only needing trivial changes (e.g. small typos etc), and you have commit access then you can merge the PR after making those changes.

As a PR reviewer, you should read through the changes and comment on any potential problems. If you see something cool, a kind word never hurts either! Additionally, you should follow the testing instructions and manually test the changes. If the instructions are missing, unclear, or overly complex, feel free to request better instructions from the submitter. Unless the PR is a draft, if you approve the review and there is no other required discussion or changes, you should also go ahead and merge the PR.

Issue Triage

If you are looking for a way to help the project, triaging issues is a great place to start. Here's how you can help:

Responding to questions

Q&A is a great place to help. If you can answer a question, it will help the asker as well as anyone who has a similar question. Also in the future if anyone has that same question they can easily find it by searching. If an issue needs reproduction, you may be able to guide the reporter toward one, or even reproduce it yourself using this technique.

Triaging issues

Once you've helped out on a few issues, if you'd like triage access you can help label issues and respond to reporters.

If an issue is a bug, and it doesn't have a clear reproduction that you have personally confirmed, label it needs reproduction and ask the author to try and create a reproduction, or have a go yourself.

Closing Questions

  • Duplicate issues should be closed with a link to the original.
  • Unreproducible issues should be closed if it's not possible to reproduce them (if the reporter drops offline, it is reasonable to wait 2 weeks before closing).
  • bugs should be closed when the issue is fixed and released.
  • features, maintenances, should be closed when released or if the feature is deemed not appropriate.