#Contributing

#Playground.vue

The Playground file is a cleanroom used for Vuetify development and is the recommended way to iterate on changes within the framework.

<template>
  <v-app>
    <v-container>
      <!--  -->
    </v-container>
  </v-app>
</template>

<script setup>
  //
</script>

#Automated testing

Vuetify uses Vitest for unit tests, Vitest browser mode with Playwright for component interaction tests, and Vizzly for visual regression tests.

• pnpm test - run all tests
• pnpm test:unit - run only unit tests
• pnpm test:browser - run only browser tests
• pnpm test:open - run browser tests in a chrome window
  • use this if you need devtools to debug a failing test
• pnpm test:screen - run only screenshot tests, saves a report to http://localhost:47392/
• pnpm tdd - start the vizzly dev server, follow with test, test:screen, test:browser, or test:open to actually run tests. Screenshot baselines and diffs can be managed and viewed at http://localhost:47392/
  • run pnpm tdd:stop when you’re done to kill the background process

The test:* commands all accept a list of test names to filter by, eg. pnpm test textfield textarea to only run VTextField and VTextarea tests.

#Adding API Documentation

When creating a new component (or composable, though this is typically done by the Vuetify team), you need to add a corresponding JSON file named ComponentName.json in packages/api-generator/src/locale/en/. This file should contain descriptions for props, slots, events, and exposed methods. After adding or updating JSON files, run pnpm build api to regenerate the dist language files. Keep in mind:

• Changes to Vuetify require a rebuild before building the API
• The API must be built before running the documentation server

Enabling developer mode in the documentation settings will allow you to see the source of truth on API description pages.

#Choosing a base branch

Before starting development you should know which branch to base your changes on. If in doubt use master as changes to master can usually be merged into a different branch without rebasing.

# Switch to the desired branch
# v4
git switch master
# v3
git switch v3-stable

# Pull down any upstream changes
git pull

# Create a new branch to work on
git switch --create fix/1234-some-issue

Commit your changes following our guidelines, then push the branch to your fork with git push -u fork and open a pull request on the Vuetify repository following the provided template.

#For Docs - Language

We do not accept PRs for any documentation changes pertaining to languages other than en. All changes for languages other than en are to be submitted through our Crowdin project. You can help translate in one of 2 ways:

• Using in-context translation service directly through the documentation site. To get started simply select Help Translate in the language drop down in the docs.
• Directly through the Crowdin project.

Note: Languages will not be added to the language drop down on the docs site until they have at least 50% of their translations completed.

#General Rules

• Commit messages must have a subject line and may have body copy. These must be separated by a blank line.

• The subject line must not exceed 60 characters

• The subject line must be written in imperative mood (fix, not fixed / fixes etc.)

• The body copy must include a reference all issues resolved:

  docs(sass-variables): fix broken link to api
  
  resolves #3219
  resolves #3254
  

• The body copy must be wrapped at 72 characters

• The body copy must only contain explanations as to what and why, never how. The latter belongs in documentation and implementation.

#Commit types

The following is a list of commit types used in the angular preset:

• feat: Commits that result in new features or functionalities. Backwards compatible features will release with the next MINOR whereas breaking changes will be in the next MAJOR. The body of a commit with breaking changes must begin with BREAKING CHANGE, followed by a description of how the API has changed.
• fix: Commits that provide fixes for bugs within vuetify’s codebase.
• docs: Commits that provide updates to the docs.
• style: Commits that do not affect how the code runs, these are simply changes to formatting.
• refactor: Commits that neither fixes a bug nor adds a feature.
• perf: Commits that improve performance.
• test: Commits that add missing or correct existing tests.
• chore: Other commits that don’t modify src or test files.
• revert: Commits that revert previous commits.