We just released Vuestic Admin 3.0 🤗
🔥🔥🔥 Hire us

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 using yarn install

Packages
#

Vuestic has few packages in order of importance for newcomers:

  • packages/ui - UI lib with demos. Here all vuestic components stored.
  • packages/docs - ui.vuestic.dev source code.
  • packages/nuxt - @vuestic/nuxt module for Nuxt3.
  • packages/sandbox - Package for testing build and treeshaking.
  • packages/tailwind - Tailwind utilities.
  • packages/ag-grid-theme - AgGrid extension styles.
  • packages/vue-cli-plugin - vue add vuestic-ui plugin for vue-cli [deprecated].
  • packages/bundlers-tests - package used for testing vuestic ui in different bundlers in CI.
  • 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 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:storybook - 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 build - this will build vuestic-ui package.

You can find more scripts in package.json of each package.

Component folder structure
#

See detailed guide here.

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 closes #<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 closes #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 closes #123 to the commit message.
  • For breaking changes add the word BREAKING to PR name, that would allow us to automatically find it before release.
  • 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 storybook environment (yarn serve:storybook). We want to keep global stuff out of components.

Credits
#

Hall of fame!