Contribution guide #
This guide describes the possible ways in which you can become a part of the ongoing development of Vuestic UI. We are really excited that you are interested in helping us make Vuestic better!
Quick start #
If you want to make some changes get a local copy of VuesticUI:
- Fork Vuestic repository
- Clone your fork
- Install dependencies with
yarn install
Packages #
Vuestic has few packages in order of importance for newcommers:
packages/ui
- UI lib with demos. Here all vuestic components stored.packages/docs
- vuestic.dev source code.packages/nuxt
-@vuestic/nuxt
module for Nuxt3.packages/sandbox
- Package for testing build and treeshaking.packages/vue-cli-plugin
- vue add vuestic-ui plugin for vue-cli.packages/ag-grid-theme
- AgGrid extension styles.packages/deploy
- Release scripts for core contributors.
Likely you will deal only with ui
and docs
packages.
Branches #
- Public branches (epicmax/vuestic-ui):
master
- releases and hotfixes only. Do not submit PR's tomaster
!develop
- main development branch.
- Local branches
- For local branches prepend your messages with
feat/
orfix/
(e.g. for a tabs-related fix it would befix/tabs
,feat/date-picker
orfix#1000/important-bug
). This is necessary to keep local branches visually separated from the public ones.
- For local branches prepend your messages with
Commonly used scripts #
yarn serve
- this will run project with demos, where you can test component features.yarn serve:docs
- this will run project with docs (deployed here vuestic.dev).yarn generate:docspage
- this will generate docs page, so you can write some guide or tutorial.yarn generate:component
- this will make component template with docs page and demo page, so you can easily start making new component.
You can find more scripts in package.json
of each package.
Component folder structure #
Pull Request Guidelines #
- The
master
branch keeps the latest stable release plus potentially some cherry-picked hotfixes. All the development should be conducted in local branches (fork of the project). - Do not submit PRs against the
master
branch. Use thedevelop
one instead. - Checkout a
feat/*
branch from thedevelop
, then create a pull request todevelop
. - It's OK to have multiple small commits as you work on your PR - we will let GitHub automatically squash them into a single one before merging.
- If fixing a bug:
- If you are resolving a certain issue, add
close #<xxx>[,#<yyy>]
(<xxx>, <yyy> is the related issues' ids) into the PR's description so that GitHub could automatically close the related issue(s) as soon as the respective commits are merged into themaster
branch (i.e. as soon as a new version of Vuestic UI is out). - Provide detailed description of the bug inside the PR in case the bug is not arranged in the form of a separate issue.
- If you are resolving a certain issue, add
For the core contributors #
- Always link a PR to its related issue (via
close #123
). - When you start working on a task - please self-assign the related issue. We don't want a lot of people working simultaneously on the same thing (except when intentional).
- For small issues you may push to the
develop
branch directly while addingclose #123
to the commit message. - Create a single PR for one issue. If we have several PRs - move all the code into a single PR and close the rest. If one PR covers several issues - either split it in several PRs or mark one of the issues as duplicate.
- Make sure to assign an issue to only a single person.
- Check your code: conventions.
- We use yarn for package management.
- Be proactive. If you think something is wrong - create an issue or discuss.
- Recommended tools: GitKraken, WebStorm, ShareX.
- If you work on UI components - work in the book environment (
yarn serve:book
). We want to keep global stuff out of components.