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


Vuestic has few packages in order of importance for newcommers:

  • packages/ui - UI lib with demos. Here all vuestic components stored.
  • packages/docs - 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.


  • Public branches (epicmax/vuestic-ui):
    • master - releases and hotfixes only. Do not submit PR's to master!
    • develop - main development branch.
  • Local branches
    • For local branches prepend your messages with feat/ or fix/ (e.g. for a tabs-related fix it would be fix/tabs, feat/date-picker or fix#1000/important-bug). This is necessary to keep local branches visually separated from the public ones.

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
  • 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 the develop one instead.
  • Checkout a feat/* branch from the develop, then create a pull request to develop.
  • 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 #&lt;xxx&gt;[,#&lt;yyy&gt;] (<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 the master 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.

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 adding close #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.