Skip to content

Latest commit

 

History

History
131 lines (86 loc) · 5.91 KB

CONTRIBUTING.md

File metadata and controls

131 lines (86 loc) · 5.91 KB

Contributing to TAPSI Design System's Monorepo

If you're reading this, you're definitely awesome!
The following is a set of guidelines for contributing to TAPSI Design System's Monorepo, which are hosted in the TAPSI Design System's Monorepo. These are mostly guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request.

Code of Conduct

This project and everyone participating in it is governed by the Code of Conduct. By participating, you are expected to uphold this code.

A large spectrum of contributions

There are many ways to contribute, code contribution is one aspect of it. For instance, documentation improvements are as important as code changes.

Your first Pull Request

Working on your first Pull Request? You can learn how from this free video series:

How to Contribute to an Open Source Project on GitHub

To help you get your feet wet and get you familiar with our contribution process, we have a list of good first issues that contain changes that have a relatively limited scope. This label means that there is already a working solution to the issue in the discussion section. Therefore, it is a great place to get started.

We also have a list of good to take issues. This label is set when there has been already some discussion about the solution and it is clear in which direction to go. These issues are good for developers that want to reduce the chance of going down a rabbit hole.

You can also work on any other issue you choose to. The "good first" and "good to take" issues are just issues where we have a clear picture about scope and timeline. Pull requests working on other issues or completely new problems may take a bit longer to review when they don't fit into our current development cycle.

If you decide to fix an issue, please be sure to check the comment thread in case somebody is already working on a fix. If nobody is working on it at the moment, please leave a comment stating that you have started to work on it so other people don't accidentally duplicate your effort.

If somebody claims an issue but doesn't follow up for more than a week, it's fine to take it over but you should still leave a comment. If there has been no activity on the issue for 7 to 14 days, it is safe to assume that nobody is working on it.

Sending a Pull Request

Pull Requests are always welcome, but, before working on a large change, it is best to open an issue first to discuss it with the maintainers.

When in doubt, keep your Pull Requests small. To give a Pull Request the best chance of getting accepted, don't bundle more than one feature or bug fix per Pull Request. It's often best to create two smaller Pull Requests than one big one.

  1. Fork the repository.

  2. Clone the fork to your local machine and add upstream remote:

git clone https://github.com/<your username>/web-components.git
cd web-components
git remote add upstream https://github.com/Tap30/web-components.git
  1. Synchronize your local main branch with the upstream one:
git checkout main
git pull upstream main
  1. Install the dependencies with pnpm (npm and yarn aren't supported):
pnpm install
  1. Create a new topic branch:
git switch -c my-topic-branch
  1. Make changes, commit and push to your fork:
git push -u origin HEAD
  1. Go to the repository and make a Pull Request.

The core team is monitoring for Pull Requests. We will review your Pull Request and either merge it, request changes to it, or close it with an explanation.

Development server

Start developing server and watch for code changes:

pnpm dev

The local dev server is a Vite app. You can import codes and make changes to playground/src/index.ts (for native stuffs) or playground/src/react-root.tsx (for React stuffs). Additionally, you might need to change playground/index.html to use your registered web components.

Building

You can build the project, including all type definitions, with:

pnpm packages:build

Testing

To run all the tests, run:

pnpm test

Coding style

Please follow the coding style of the project. We use prettier and eslint, so if possible, enable linting in your editor to get real-time feedback.

Git Commit Messages

  • Use the present tense ("Add feature" not "Added feature")
  • Use the imperative mood ("Move cursor to..." not "Moves cursor to...")
  • Limit the first line to 72 characters or less
  • Reference issues and pull requests liberally after the first line
  • Please use the following commit message conventions for consistent and informative commit history:
    • feat: A new feature
    • fix: A bug fix
    • docs: Documentation only changes
    • style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
    • refactor: A code change that neither fixes a bug nor adds a feature
    • perf: A code change that improves performance
    • test: Adding missing or correcting existing tests
    • build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
    • ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
    • chore: Other changes that don't modify src or test files
    • revert: Reverts a previous commit

License

By contributing your code to the Tap30/* GitHub repositories, you agree to license your contribution under the MIT license.