# Lottify

## Micro-frontends based Vue application condensed into one monorepo managed by lerna.

## Business objectives of this project

Lottify, your digital lottery shop!\
It’s your lottery shop out-of-the-box with just a few clicks to set up. It’s a SaaS solution and comparable to e.g. “Shopify” without of the box functionality.
Main goal of the application is to manage your organizations and create gambling shops quickly across different markets like US or MX. As the lottery industry is highly regulated, you can quickly create shops across licensed territories (licensed per state in the USA) like NY or NJ.
MVP version will be used inside of Lotto.com with custom-built shops, but after MVP we will expand our application and try to sell it to B2B or B2G clients with shop designed by us which is handled by Team Drago ([Shopfront](https://gitlab.lottocom.dev/lottify/shopfront)).

## Useful links in our project

- [Jira - current sprint board](https://lottocom.atlassian.net/jira/software/c/projects/RCKY/boards/60)
- [Jira - Dashboard](https://lottocom.atlassian.net/jira/dashboards/10111)
- [Designs on Figma](https://www.figma.com/file/P8PTmcEkarood5rVnVzIFe/Rocky-Workspace)
- [Lottify FE on GitLab](https://gitlab.lottocom.dev/lottify/frontend/platform-frontend) - Monorepo with few smaller packages inside
- [Lottify UI on Gitlab](https://gitlab.lottocom.dev/lottify/shared/shared-vue-components) - Our UI lib just like Vuetify or Quasar
- [Lottify architecture board](https://miro.com/app/board/o9J_lq9GExc=) - Miro board which can help you understand how lottify works behind the scene

## Environments (Most of them via VPN)

- [Production](https://app.lottify.com) - Lottify on production
- [Dev](https://app.lottify.dev) - Staging
- [GraphQL Playground](https://playground.lottify.dev) - Test your new API calls
- [Storybook](https://storybook.lottify.dev) - You can preview here what component we already have
- [Feat-env overview](https://overview.lottify.dev) - We can create new feature environments and manage them
- [Lighthouse](https://lighthouse.lottify.dev) - We're gathering here information about our lighthouse scores
- [Phrase](https://phrase.com) - Translation service for our app. Contact team lead if you need credentials to change something there
- [Keycloak](https://auth.lottify.dev/keycloak) - Our authentication provider, we can sign in here to administrator console
- [JFrog Artifactory](https://repo.lottocom.dev/ui/login) - Our private npm registry managed by DreamIT

## Technologies

- [Vue.js](https://vuejs.org/) - with composition API
- [Storybook](https://storybook.js.org/) - for component documentation
- [TypeScript](https://www.typescriptlang.org/) - for static type safety and ease of development, documenting and extending functionality
- [SASS](https://sass-lang.com/) - to have Syntactically Awesome Style Sheets 🙂 (DRY and easy to maintain CSS)
- [Lighthouse](https://github.com/GoogleChrome/lighthouse) - to keep track on how good is our markup and to make sure we use the best practices at all times
- [GraphQl](https://graphql.org) - A query language for our API

### Libraries

- [Apollo](https://www.apollographql.com) - our GraphQL solution
- [Lerna](https://lerna.js.org) - A tool for managing JavaScript projects with multiple packages.
- [Vuelidate](https://vuelidate-next.netlify.app) - form validation for vue.js
- [Vue-Portal](https://portal-vue.linusb.org/) - for window modal functionality
- [Vuex Persisted State](https://github.com/robinvdvleuten/vuex-persistedstate#readme) - We're using it to keep vuex state in localstorage
- [Svg to vue component](https://github.com/egoist/svg-to-vue-component#readme) - Easier usage SVG Images in code
- [Husky](https://typicode.github.io/husky/) - We have husky pre-commit hook implemented to keep our code clean
- [Cypress](https://www.cypress.io) - our E2E tool
- [Keycloak](https://www.keycloak.org/) - our authentication provider

## Project Setup

1. Clone repo from GitLab

- Clone the repositories using `git clone [e-mail]:lottify/frontend/platform-frontend.git`
- Create file for Artifactory access in the root directory
- The next step is to create `.npmrc` in root folder the same level as `/packages`
- Login to [JFrog](https://repo.lottocom.dev) via GitLab
- Go to your account settings (top right corner → Edit Profile)
- In Authentication Settings section generate your IDENTITY TOKEN (press “Generate an Identity Token”) and copy to `.npmrc`
- it should look like:

    registry=https://repo.lottocom.dev/artifactory/api/npm/npm/
    //repo.lottocom.dev/artifactory/api/npm/npm/:always-auth=true
    //repo.lottocom.dev/artifactory/api/npm/npm/:save-exact=true
    //repo.lottocom.dev/artifactory/api/npm/npm/:_authToken=<YOUR_PERSONAL_IDENTITY_TOKEN_FROM_JFROG>

- Create `streamlinehq.json` file in the root directory, for icons access purposes (ask teammates for the secret)
- Remember to **never** push `.npmrc` file to repo - it is git-ignored for a reason. After you done that run 'yarn' to install all dependencies. After all dependencies finish installation you can run 'yarn serve' to set up local development environment. Here is step-by-step instruction:

2. Make sure you have installed all:

  - YARN v1.22.17
  - NODE v14.18.2
  - LERNA v4.0.0 (or higher)

3. Install dependencies in the root directory: `yarn install`
4. Install dependencies in each package with one command: `lerna bootstrap`

  If necessary you should run both commands
  - yarn build:packages:dev
  - yarn build:packages

5. Serve the wrapper project on `localhost:8080` with `yarn serve`
6. You can also work on one of the packages
1. Run one package by entering in its directory (i.g. shop)\
`cd ./packages/shop && yarn serve`

## Working with custom backend

To be able to work on custom backend we need to create `.env.developement` in wrapper folder: \
**! Remember to not put `.env.developement` into repo !**

VUE_APP_BACKEND_URL=
VUE_APP_KEYCLOAK_REALM=

Base is `env_name` from feat-env

Keycloak_realm is prefixed by - `lfy-`

Backend_url ends with `-api` in my case it was:

VUE_APP_BACKEND_URL=https://ft-rcky-1466-ups-api.lottify.dev
VUE_APP_KEYCLOAK_REALM=lfy-ft-rcky-1466-ups

## Vuex

We have vuex divided in `shared`, `shop`, `account`, `organization`, `authorization`.

Each module have it own namespaceHelper() from where we can get `actions`, `getters`, `state` and `mutations` basically we follow standard as `[moduleName]NamespaceHelper`

We also have `BusyNamespaceHelper` to easier get to our busy state per module except shared (i.e. `shopBusyNamespaceHelper`)

### Some of Vuex rules

- Action names are always camel case: `getOrganizations`
- Getter names are always camel case without the "get"-prefix: `currentOrganization`
- Mutations names are always upper case beginning with
- `DELETE`: for mutations that delete something from store (i.g., `DELETE_MEMBER`)
- `SET`: for mutations that set a value in the store to some value, independent of what the value was before (i.g., `SET_MEMBERS`)
- `UPDATE`: for mutations that change existing objects (for simple fields `SET` and `UPDATE` are semantically the same, and so far we have only used SET, i.g. `SET_BUSY_FETCHING_MEMBERS`)
- `UPSERT`: for mutations that act as UPDATE for existing ones and as SET for new ones (i.g., `UPSERT_MEMBERS`)

### Any questions?

1. #### Why SET_BUSY_FETCHING_MEMBERS over SET_START_FETCHING_MEMBERS ?

- We didn't use something like `SET_START_FETCHING_MEMBERS` and `SET_STOP_FETCHING_MEMBERS`, but `SET_BUSY_FETCHING_MEMBERS`.
- It's one mutation less that you have to write, and it's more consistent with the other mutations like `DELETE_MEMBER`, `SET_MEMBERS`, `UPSERT_MEMBERS` which always expect a parameter when they are called.

## Branches

Each feature branch name should follow the following convention (all lowercase) `${prefix}-${jiraTask}-${hyphen-delimited-string}` for example, `ft-rcky-374-integ-prot`. Also, the name of the branch should not be longer than 24 letters.
When creating branch us following naming convention:

## Merge Requests
MR name should start with *[Ticket-ID] - created shop world map*

In merge request please assign it to yourself and rest of the team as a reviewers\
Add approval rule if there isn't any and assign `Frontend group` to do approval\
Direct pushes to master are forbidden. Changes in the source code may only end up in master by MR\
When you have a remark for a small change, you might also provide a fix in you comment. It'll make it easier to fix it.

#### Why are we not doing squash before merge?

The reason is the following: Using squash on merge can lead to problems when people branch off of feature branches.
- Assume somebody is working on feature branch A and has made commits `A: a-b-c`, now somebody wants to develop their new feature B based on A. They branch B off A and have branch `B: a-b-c`
- Now the first developer is making more changes to A `A: a-b-c-d-e-f-b` including commit `b` that reverts the previous changes from commit `b`. The developer is opening a merge request to master and uses squash on merge. All commits from A are combined into one commit on master branch.
- Now the second developer is has finished their work on feature branch B `B: a-b-c-x-y-z` , has also opened a merge request and set it to squash on merge.
- Now comes the problem: Git cannot detect that commits `a-b-c` are already on master. When `B` is merged to master (squashed or not, does not matter) it will re-apply the changes from commit `b`, thereby overwriting changes from commit `b`.

In the past, we have used this “branch off feature branch” sometimes. And it could have let to problems if we had squashed.\
Conclusion: Allowing “squash on merge” requires developer discipline to never branch off anything else than master. And in the past we decided that we prefer the flexibility (branching off where you want) over the conciseness of squashed merge requests.

#### Prefixes

- `ft`: A new feature
- `bf`: A bug fix
- `rf`: (refactor) A code change that neither fixes a bug nor adds a feature
- `hf`: A hotfix
- `pc`: Proof of Concept
- `ms`: (miscellaneous) For other purposes

Example: **ft-rcky-55-section**

## Project management:

#### Jira
Main source of truth for the work progress and what is being/has been done:
- We are setting priorities in Jira
- P1 - Business related tasks which bring most value to the app or stakeholder requests
- P2 - Business related task but maybe not so much necessary as P1, or we are not able to deliver them first and backend need to do it first
- P3 - Technical dept, code improvements, some forgotten unit tests
- We're operating basically only on 2 types of tickets in jira
- Bugs - Should be taken as soon as possible because of DreamIT policy
- Task - We should take firstly tasks with the highest priority
- If you create task you should add there label is it task for backend `BE` or frontend `FE`
- Road Map tab (with estimated dates planned - adjusted around each quarter)
- Comments regarding QA are there (Jira issue) and task state should generally reflect it’s current progress (every day before daily we should update our tasks)
- Release and potential blockers is discussed on team daily meetings
- Stories should be named the way `As an user ...`
- The story should be defined before the task
- Status of stories should be tracked on daily

#### Communication:
Slack channels:
- team-lottify - All things project related ( Mostly announcements )
- team-rocky-all - All things project related, but we are also announcing here about our absence from work if it is short one (i.e. ***I will be unnavigable from 12 to 14 today because of doctor appointment***)
- team-rocky-uiux - Designs discussion and our requests to design
- team-rocky-status - Geekbot channel where is presented our daily status from last day, we should be careful what we are writing there because our stakeholder reads it
- team-rocky-qa - We have announcement here when we switch from code review to QA section ( Mostly useful for our testers )
- team-rocky-gitlab - We have here slackbot to announce about every new shared ui package, wrapper build fail on master branch, and also we put here our MR links for other FE
- team-rocky-frontend - We're talking here about FE topics only
- team-rocky-frontend-poker - During refinement we are playing poker to estimate story point for each task
- team-rocky-bugs - Bug reporting: mark all bugs reported in Jira with :white_check_mark: so we can easily see if those reports won’t be lost somewhere on slack
- team-rocky-devtalk - We're posting here interesting learning materials for both FE and BE guys
- team-rocky-feat-envs-list - List of all currently running feature environments, we are also pinging people who create feat-env to not overcharge stakeholders with $$$

Geekbot:
Every day from Mon to Fri we are asked what we were doing yesterday and there are 2 question for us
- ***What did you do since yesterday?*** - We are answering to it in bullet point and please follow this rule
- ***Anything blocking your progress?*** - If we have problem with task, something seems to be hard for us this is good place to announce it we always try to help! (to skip, answer with 'no')

## Workflow

When you get assigned a task in Jira and want to start working on it move it to 'in progress'. Then, create a feature branch which [includes jira issue number](#branches) and start working on the feature. When in doubt, always consult UX/UI team (on the team-rocky-uiux channel on slack - for transparency) or other developers that are working or have worked on the project in the past. When making a decision in regard to technical solution, keep project's business goals in mind - it will help to guide you to a solution. When working on a feature remember that quality is super important - we want it to be pixel perfect, and it will be checked very thoroughly. Be mindful of how your changes can affect already reviewed features - don't break stuff that's already working by rushing to finish feature quickly.
When you're done with the feature do your own CR (before committing changes). Be very critical - 'is this readable for others?', 'did I made this functionality as simple as possible?', 'could I have maybe done it in a different way and reduce the size of the feature?' - this will not only make you a better developer over time but will also save you time on potential fixes after someone else's Code Review. Keep refactoring but make sure you understand given component, and it's usage. When you move a branch to QA make sure that you link feature branch environment ([you can find it in your platform-frontend MR -> Label](#merge-requests)) in the comment under Jira ticket so that the QA person can find it easily.

Before feature will pass QA, create MR and link it on ```team-rocky-gitlab``` channel on slack and ask for a Code Review (ping @rocky-fe). **Never** merge any feature without at least one approval.

## Naming of the commits

Examples:
- **'Created cta section and handled it's rwd'**
- **'Updated README file'**

Please be aware of that commits are not only for you but also for other developers, and they should tell us something spamming `fix`, `fix`, `fix` won't fix your code


## Project Code Conventions and Choices

#### Clean code

When writing anything, keep in mind what good, clean code is all about - we want this project to be easy to debug or extend in the future. That means we want it to read like English language - just reading names and language/library specific keywords should be enough for us to imagine *what* is going on under the hood. We don't want short, 'clever' code. We want SMART and EASY TO READ code. This is especially important when it comes to naming functions/variables. Instead of 'mapAcc2UsrAddrVal' call a function 'getUserAddress' and type its parameter as 'UserAccount'. This is only an example - use common sense and try to be smart, not clever :)

Also, before you commit your code, read it. Go through all changes you've made and make sure **all** of them are necessary. Remember: Good code isn't the code you cannot *add* anything to. Good code is the code you cannot remove anything *from*.

## Conventions / rules

- We are putting our MR links in `team-rocky-gitlab` like this:
![cr](https://i.imgur.com/DsSNTeN.png)
- One developer shouldn't have more than 2 task in progress at the same time.
- Please assign MR to yourself and rest of the team as a reviewers.
- We are trying to spend at least 30 minutes each day on code reviews.
- Import using `'@'` symbol, not `'~'`.
- When writing class names for components use BEM methodology for naming elements (using '__' prefix) and modifiers (using '--' prefix).
- When adding the 'key' attribute to an item in 'v-for', you may just simply use its `index` value. In a scenario where mutation of the data array (deletion / creation of a new item) is to be expected, usage of a unique `id` property as `key` on the actual items is highly recommended. The uniqueness of a key only matter for children of a common parent, hence adding any sort of static prefixes will have no positive effect ([reference](https://vuejs.org/v2/api/#key)).
- Put QA links into Jira ticket and while moving from code review tab to QA assign QA Tester to task.
- When naming any of our project's custom components in shared UI use 'Lfy' as it's prefix and don't use any suffix
- After importing component, use it in the template like this: `<lfy-tooltip></lfy-tooltip>`.
- Do not use `Lfy` prefix for naming types. Try to use a name that will describe the types purpose (i.e. enum 'ButtonVariants' instead of enum 'Variants').
- Types and Components should have at least 2-words name.
- Always use at least `rel="noopener"` attribute on links pointing to other domains.
- Images from Figma need to be downloaded in 2x quality (for retina screens).
- Always name any components you create.
- For spaces values we should use multiplications of 8, if you write it in scss file and want to get for example 16px we just use something like this `#{$base-space-size * 2}px`.
- Remember to be aware with destructuring props - it might cause lost of reactivity of a child component if your internal logic depends on it and can cause you to write unnecessary watchers/computed or other `hacks` to fix something that usually works out of the box.
- Use prefix for boolean props wherever it makes sense:\
  `is`: for visual/behavior variations. e.g. `isVisible`, `isEnable`, `isActive`\
  `can`: fore behavior variations or conditional visual variations. e.g. `canToggle`, `canExpand`, `canHaveCancelButton`\
  `has`: for toggling UI elements. e.g. `hasCancelButton`, `hasHeader`\
- Every asset (image, video, svg) that is imported by ```webpack``` should be placed in the ```/assets``` folder.
- Avoid creating component logic that might drastically change its layout right after hydration. An example could be a JS implemented breakpoints for displaying / hiding an element.
- Use static npm dependencies version (ie. Use “typescript”: `“4.4.4”` not “typescript”: `“^4.4.4”`)
- When ***Lottify*** will be on production we should require at least 2 approval per MR
- Commits should tell us something, not spamming ***fix, fix, fix*** (i.e. 'Change of typescript version from `4.4.4` to `4.5.4`')
- In testing we try to use `mount` as much as we can in some special cases we can use `shallowMount`
- Parameter name in vuex should be called `payload` and typed properly
- Avoid leaving console.log in our application without a reason (Provide some description when you left console.log for others)
- Stick to HTML [semantic](https://www.freecodecamp.org/news/semantic-html5-elements) tags
- Avoid adding classes, styles, html tags for later 
- Keep `i18n` prefixes in locales/index.ts and export it all over the app
- We prefer to use naming exports instead of export default because of possibility to do some typos easy
- Avoid hard coding values which may be got from enum or some mock values
- Keep all regular expressions in one place
- Keep all timeouts in one place and use it as a multiplication of 1s
- Translation key are using camelCase so please be aware to use it like this `newShopButton` instead of `NewShopButton` or `new-shop-button`
- All const names should be done in uppercase (i.e. `SHOP_PREFIX`)
- We are trying to avoid using `any` type in our application because of Vue 2 we need to do it but maybe somehow we can fix it in future so when you see possibility to improve typing please do it
- In test, we can use `any` is too complicated, simply types should be provided
- When you are working on current task and there is possibility to refactor / upgrade code quality don't hesitate, everybody here wants to be better and better as a developer
- Views names should have suffixed `View` (i.e. `GeolocationView`)
- When we using namespaceHelpers for Vuex we should name it as module `useShopGetters` instead of `useGetters`

## Feature environments

Feature environments are used to ease development and enable testing features directly in the cluster, having a fully isolated and working environment. The idea is to create a new environment, which should be a copy of Production, add your changes and make the environment more and more mature. When it becomes steady (contains all Production features and the new feature/bug fix) it can be safely QA tested and merged into master, therefore causing Production deployment.

![feat-envs](https://i.imgur.com/b2x2Hgn.png)

they can be managed by [Feat-env overview](https://overview.lottify.dev) easily create or delete.\
Most useful parameters for frontend developers are 
- `ENV_NAME` - Name of the environment. Its mandatory and very important to make it short, lowercase and avoid special characters (lowercase letters, number and - are allowed) (i.e. `ft-rcky-348-members`),
- `ACTION` - Can take `DEPLOY_FAKE`, `DEPLOY` or `DELETE` as a value. First one is the default and creates the environment without a real shop schedulers on backend side, second one will create shop with real schedulers. The other deletes it. 
- `WRAPPER_BRANCH` - Defaults to master. You can choose which branch of the platform-frontend to deploy. (i.e. `bf-rcky-633-sidebar-fix`)

More useful information about limitations, how does it work behind the scene you can read [here](https://lottocom.atlassian.net/wiki/spaces/LFY/pages/1225916417/Feature+environments)

## Storybook

Main purpose of Storybook in our project is to have a visual representation of our components as well as a sandbox where developers may quickly learn about their features and their basic usage.

To see available components go to [Storybook](https://storybook.lottify.dev). To develop them and see a preview run ```yarn storybook```.
When writing stories for new components remember to:

- Make sure first example for a given story is a common use case and to set proper defaults (displayed for props in docs tab) as well as all properties for props that are type of object (so other engineers can edit them in docs without wondering what options they have available).
- After you create first example add couple more, covering most common cases (for visual representation).
- Keep your stories organized by a folder structure that represents their location in a project.
- Always try to write a brief description of a prop (at least one sentence).
- When you don't find a specific component on Storybook, chances are good that there still is an example. Try `yarn serve` to see them.

## Structure of folder and files in project

We should stick with creating 1 folder per component so inside of component there should be
- ProviderConfiguration
  - ProviderConfiguration.vue
  - ProviderConfiguration.scss
  - ProviderConfiguration.spec.ts

If there is folder with views and inside you should have route children

- IntegrationView
  - IntegrationView.vue
  - IntegrationView.scss
  - IntegrationView.spec.ts
  - Children
    - Brokering
      - BrokeringView.vue
      - BrokeringView.scss
      - BrokeringView.spec.ts
    - GeolocationView
      - GeolocationView.vue
      - GeolocationView.scss
      - GeolocationView.spec.ts

## Frontend code formatting

We use following tools for static code analysis

- [Eslint](https://eslint.org/) for .ts and .vue files
- [Stylelint](https://stylelint.io/) for styling in .vue `<style>` and .scss files 


[Some more information here](https://lottocom.atlassian.net/wiki/spaces/LFY/pages/1640988731/Frontend+Code+Formatting)

## Demo

Please remember about following points when you're presenting something:
- We are obligated to show features on **app.lottify.dev**
- Answer 3 question before presentation
  - Why we are doing it?
  - What’s the business need?
  - Context (a broader view of the solution, its place in the system)
- [Live presentation](https://docs.google.com/presentation/d/1rFdUY_7GAzlERANIkE9n9WF3A46dABAaaQcKWQYB8lE/edit?usp=sharing) (Just remember to tell a couple of words about your solution)

## Story points

Values we use for estimating tasks: 1, 2, 3, 5, 8, 13, 21

- 1 means that a story/task is a quick shot (should take max 2h)
- 2, 3, 5 - values between 1 and 8 (3 is around 1/2 days, 5 is more like 3/4 days)
- 8 means that a story/task will take a week or so
- 13 - means that a story/task will take the entire sprint to complete
- 21 - means that a story/task is too big, and we should split it

## Jira useful links

- [Development Rules](https://lottocom.atlassian.net/wiki/spaces/LFY/pages/1047429163/Development+Rules)
- [Work Organization](https://lottocom.atlassian.net/wiki/spaces/LFY/pages/971210931/Work+Organization)
- [Important Links](https://lottocom.atlassian.net/wiki/spaces/LFY/pages/983564856/Important+Links)
- [Feature Environments](https://lottocom.atlassian.net/wiki/spaces/LFY/pages/1225916417/Feature+environments)
- [Error codes](https://lottocom.atlassian.net/wiki/spaces/LFY/pages/1101561894/Services)
- [Vuex Conventions](https://lottocom.atlassian.net/wiki/spaces/LFY/pages/1445396992/Frontend+Conventions+for+VUEX+Store)
- [What is in our JWT token](https://lottocom.atlassian.net/wiki/spaces/LFY/pages/2101674004/Lottify+JWT+Tokens)
- [Shop Uniqueness](https://lottocom.atlassian.net/wiki/spaces/LFY/pages/2170388499/Shop+uniqueness+across+feat-envs)
- [Translating Emails](https://lottocom.atlassian.net/wiki/spaces/LFY/pages/2338979856/Translating+Email+Templates)
- [Frontend URL Paths](https://lottocom.atlassian.net/wiki/spaces/LFY/pages/1346174988/Frontend+URL+Paths+Schema)
- [Technical Debt Improvements](https://lottocom.atlassian.net/wiki/spaces/LFY/pages/1657077761/Technical+Debt+Improvements)
- [Gateway API Changes](https://lottocom.atlassian.net/wiki/spaces/LFY/pages/2372337675/Gateway+API+changes)

## Script to assign people to reviewers

Hello guys, there is small gists for FE and BE reviewers (small update, and now it has one source of truth, gist will be replaced with AWS instance when we get access)
- BE -> https://gist.github.com/BuuBux/a604760806fd02f4e5b66c7d36db627e
- FE -> https://gist.github.com/BuuBux/3993cefd848d0c06c3e124de4809b60d

Use Tampermonkey or if you are using Safari and don’t want to pay 10 PLN use Userscripts\
How to setup?

// ==UserScript==
// @name Backend/Frontend Group Reviewers
// @version 0.1
// @description Add all backend/frontend folks as reviewers to mr
// @include *
// @run-at document-start
// @require http://code.jquery.com/jquery-latest.js
// @require !!! HERE USE RAW GIST SCRIPT !!! (i.e. https://gist.githubusercontent.com/BuuBux/3993cefd848d0c06c3e124de4809b60d/raw/8c29f0fb06e74dd80c5c23f73cc575d4d896c687/reviewers.js)
// ==/UserScript==

I know @include can be done better but for me, it wasn’t working maybe I don’t know regex

## Supported browsers

We focus on supporting most used internet browsers and their most recent releases (last 2-3 versions). This means we target: Edge, Firefox, Chrome, Safari, Opera. When in doubt, always take a look at [Can I Use?](https://caniuse.com)

Please leave a feedback about onboarding to your team leader