realaravinth/debian-mirror-gitlab
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
debian-mirror-gitlab/doc/development/fe_guide/index.md
Pirate Praveen 574775de31 New upstream version 9.5.4+dfsg
2017-09-10 17:25:29 +05:30

4.9 KiB
Raw Blame History

Frontend Development Guidelines

This document describes various guidelines to ensure consistency and quality across GitLab's frontend team.

Overview

GitLab is built on top of Ruby on Rails using Haml with Hamlit. Be wary of the limitations that come with using Hamlit. We also use SCSS and plain JavaScript with modern ECMAScript standards supported through Babel and ES module support through webpack.

We also utilize webpack to handle the bundling, minification, and compression of our assets.

Working with our frontend assets requires Node (v4.3 or greater) and Yarn (v0.17 or greater). You can find information on how to install these on our installation guide.

jQuery is used throughout the application's JavaScript, with Vue.js for particularly advanced, dynamic elements.

Browser Support

For our currently-supported browsers, see our requirements.

Development Process

When you are assigned an issue please follow the next steps:

Divide a big feature into small Merge Requests

  1. Big Merge Request are painful to review. In order to make this process easier we must break a big feature into smaller ones and create a Merge Request for each step.
  2. First step is to create a branch from master, let's call it new-feature. This branch will be the recipient of all the smaller Merge Requests. Only this one will be merged to master.
  3. Don't do any work on this one, let's keep it synced with master.
  4. Create a new branch from new-feature, let's call it new-feature-step-1. We advise you to clearly identify which step the branch represents.
  5. Do the first part of the modifications in this branch. The target branch of this Merge Request should be new-feature.
  6. Once new-feature-step-1 gets merged into new-feature we can continue our work. Create a new branch from new-feature, let's call it new-feature-step-2 and repeat the process done before.
master
└─ new-feature
   ├─ new-feature-step-1
   ├─ new-feature-step-2
   └─ new-feature-step-3

Tips

  • Make sure new-feature branch is always synced with master: merge master frequently.
  • Do the same for the feature branch you have opened. This can be accomplished by merging master into new-feature and new-feature into new-feature-step-*
  • Avoid rewriting history.

Share your work early

  1. Before writing code guarantee your vision of the architecture is aligned with GitLab's architecture.
  2. Add a diagram to the issue and ask a Frontend Architecture about it.

Diagram of Issue Boards Architecture

  1. Don't take more than one week between starting work on a feature and sharing a Merge Request with a reviewer or a maintainer.

Vue features

  1. Follow the steps in Vue.js Best Practices
  2. Follow the style guide.
  3. Only a handful of people are allowed to merge Vue related features. Reach out to one of Vue experts early in this process.

Architecture

How we go about making fundamental design decisions in GitLab's frontend team or make changes to our frontend development guidelines.

Testing

How we write frontend tests, run the GitLab test suite, and debug test related issues.

Design Patterns

Common JavaScript design patterns in GitLab's codebase.

Vue.js Best Practices

Vue specific design patterns and practices.

Style Guides

JavaScript Style Guide

We use eslint to enforce our JavaScript style guides. Our guide is based on the excellent Airbnb style guide with a few small changes.

SCSS Style Guide

Our SCSS conventions which are enforced through scss-lint.

Performance

Best practices for monitoring and maximizing frontend performance.

Security

Frontend security practices.

Accessibility

Our accessibility standards and resources.

DropLab

Our internal DropLab dropdown library.