Contributing to Jellyfin Vue

Thank you for your interest in helping us develop the next generation of the Jellyfin web client.

This document will walk you through the various ways you can contribute to this project, as well as introduce the conventions used and guide you through setting up a development environment.

Ways to contribute

There are several ways to contribute to Jellyfin Vue, in addition to writing code.

We are always looking for talented UI/UX designers to help us make Jellyfin look good, and to help improve user experience.
If you are interested in discussing this with us, the "UI & UX" category in the Discussions tab is a great place to start.
We have a translation platform, if you want to help us provide a localized version of Jellyfin in as many languages as possible.
You can report bugs to help us fix issues with the client.

Pull request process

Before making a pull request for a new feature, please open a discussion in the "Features" category of the discussions tab.

Pull requests require reviews from members of the Jellyfin Web team before being merged. Please ensure that you respect code and commit message styles. Pre-commit hooks and Commitizen support are provided to help you.

Unattended pull requests will be marked as stale after a period of 90 days without activity, then closed after 14 days. This is meant to prevent abandoned pull requests from cluttering the review process.

Conventions

This repository uses the conventional commits convention for commit messages. In order to help you with writing commit messages, we provide Commitizen support in the repository.

The following should guide you through making a proper commit message:

npx cz

Code style

This repository uses Prettier for automatically formating code. In addition, ESLint rules are provided to help you enforce good practices.

The project is written in TypeScript, and using strongly typed code is recommended and expected, where possible.

Tests

We use Jest for unit testing. For testing Vue components, usage of vue-testing-library is preferred.

When writing tests, we follow some conventions in regards to messages:

The messages for it() always start with a lowercase letter
They describe the test case in detail
Only one thing is tested per test case (If you are testing multiple branches, you would have one test case per branch)
The describe() block should contain the name of the component, store or mixin being tested

Vue components

describe('component: ComponentName', () => {
  it('shows the text "Lorem Ipsum"', (): void => {
    // Your test logic goes here
  });
});

Mixins

describe('mixin: myMixin', () => {
  it('does this when passed that value', () => {
    // Your test logic goes here
  });
});

Vuex stores

describe('vuex: storeName', () => {
  it('sets this value when myAction is dispatched', () => {
    // Your test logic goes here
  });
});

3.7 KiB Raw Blame History