Skip to content

Latest commit

 

History

History
105 lines (72 loc) · 6.45 KB

CONTRIBUTING.md

File metadata and controls

105 lines (72 loc) · 6.45 KB
Raw

CONTRIBUTING.md

Tools and Tech Stack: NextJS pages router, scss, mdx, pnpm, eslint, prettier, git

Project Structure

  • All React Components should be defined inside components.
  • All Pages should be defined inside pages.
  • Create a single directory for each component. For example, Button component should be inside components/Button/Button.jsx. All the styles related to that component should be declared as a css module inside the same directory. For example, styles related to Button component should be declared in components/Button/Button.module.scss.
  • components has an index.jsx file. After creating your component, import and export your component from index.jsx. This simplifies importing Components in pages. For example, without an index.jsx, importing Button component would look like:
import Button  from “./Components/Button/Button”

With the index.jsx file, it would be much cleaner:

import { Button }  from “./Components”
  • Follow a similar pattern for Pages as well.
  • Context Providers should go in global/

Linting

  • Install ESLint and Prettier extensions in VSCode.

  • Project uses ESLint. *Do not try to bypass eslint errors.

  • See all the rules in eslintrc.json

  • General rules to follow:

    • All Js files should be named in camelCase
    • All Jsx files should be named in PascalCase
      • camelCase (capitalize first letter from second word onwards)
      • PascalCase (capitalize first letter of all the words)
    • All directories inside src should be named in PascalCase.
    • React Components/Pages must be defined as Javascript arrow functions.

  • Not following any of the above rules will throw an error when committing your changes.

  • Optional: After writing your code, you can use Prettier to format it.

    Ctrl/Cmd + Shift + p -> Format Document with… -> Prettier

    This step is done automatically by the pre-commit hook so it is not compulsory to do this step manually.

Git Commits and Branches

  • Write proper git commit messages. Max 50 character title with a brief description below it.

  • Try to use tags in commit titles. For example “[bugfix]” for a commit that fixes a bug, “[feat]” for a commit that adds a feature and so on…

  • Keep the message brief and crisp.

  • Example of good commit messages:

  • Before working on something(features/bugs etc), general rule:

    • Pull from origin/main (git pull origin main)
    • Create a branch from the main branch.

  • Branch names should be small but descriptive of what the branch is doing. For example, if you are creating the landing page, give a branch name like landing-page.

Miscellaneous

  • Write clean and maintainable code. Use comments if necessary; for example, the structure in which a component takes props.

  • If facing problems(like long stalling/failure to authenticate) with git network commands(clone/pull/push/fetch etc).

    Fix(use any one):

    • Use Github Pull Request and Issues Vscode extension, and then authenticate with your Github account through browser. This will make those commands work only through your Vscode terminal.
    • Install Git Credential Manager. Authenticate to your Github account through the browser/popup. This will make the commands work from any terminal.

Working on components

  • Create a separate branch for your component in git. Push to github and put a PR to the home branch. This branch will be used for integration.
  • Initially put a pr with a don't-merge tag. After the feature is complete remove the tag and/or replace with other available appropriate tags then (like pls-merge).
  • Only work on your assigned feature. If any help is needed first google, rtfm (google its meaning), talk with the team members, and then contact seniors.
  • Do not touch the main branch. Push your changes only to your own branch. Those changes will be first merged in the home branch, and then the home branch will be merged to the dev branch, and then once the whole site is finished, does the dev branch get merged into the main branch.
  • The branch names for pages should be of the form {pageName}-page, eg home-page, resource-page.
  • Name the PR after the feature you are working on.

Pushing your branch

PR to home

Putting dont-merge tag`

Using css vars

  • Define css variables for commonly used colours in global.css.
  • So instead of copying and pasting the same hex codes over and over again, we can just use the vars.
  • If any colour is changed due to some design change, we just have to make a change in the var, instead of everywhere.
  • Reference code:

Further reading:

  1. A Complete Guide To CSS Variables [With Examples] | LambdaTest
  2. Using CSS custom properties (variables) - CSS: Cascading Style Sheets | MDN

Use iconify for icons

  • Use Iconify for icons. It is used by the designers as well, so the same specific icon can be used. (Package will be included in the repo, use it for icons).
  • It supports tree shaking i.e. only used icons are built, and discarding the rest, keeping the build size to whatever you actually use.