Formatting && Indentation

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
push-website	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	May 16, 2024 11:59am

[rohitmalhotra1420]

@corlard3y could you please add more details in the ticket description.

• What the change is about and why it was neede?
• What did it solved?
• What approach are we using here hand how is it working?
• The files which were affected to implement this approach, just the script or config file and not the formatted files.

[corlard3y]

• Why changes are needed?: A lot of files were not formatted properly and also had indentation problems, so it is necessary to have a codebase with consistent coding patterns and rules to improve readability. Over time, inconsistencies had crept into the codebase, making it difficult for developers to navigate and understand the code.

• What did it solve? : By addressing inconsistencies in formatting and indentation, this PR resolves issues related to code readability, maintainability, and collaboration. Clear and consistent code formatting makes it easier for developers to understand, modify, and debug code, ultimately leading to improved productivity and reduced risk of errors.

• What approach are we using here and how is it working?: This PR needed third party libraries like eslint, prettier, lint-staged and husky essentially to set up formatting, during coding, while saving and also or pre-commit checks. So firstly, the .prettierrc file was updated with consistent formatting rules across codebase. .eslintrc.js was updated to enforce formatting rules. Husky automatically lints your commit messages, code, and run tests upon committing or pushing based on how you structure it to perform. Lint-staged runs linters, against staged files and does not allow unformatted code or errors into your codebase. So the whole codebase was affected on adding the prettier rules, but from onward commits - only staged files or updated files will be affected or checked during the pre-commit check. Also, the changes are just applied within the src file - the assets, blogs and docs are outside src file. And the eslint rules were not set for these files(Pls,advise on this if you think otherwise) because we are using the @typescript-eslint/parser in eslint,so the src files that holds pages, components and other segments get checked according to the parser rules.

Also, added other props within the eslint file to work consistently within the project scope, like env, parserOptions and rules. We can check through both the prettier and eslint files to see what can be adjusted or changes as this should be generally agreed by the dev team.

For lint-staged - on running commits(pre-commit). It runs 'prettier --write' and 'eslint' within staged {js,ts,jsx,tsx,json} files in src files, and provides a response based on errors and warnings(if any). Otherwise, it commits successfully and you can push changes to remote as well.

• The files which were affected to implement this approach, just the script or config file and not the formatted files: The config files were the prettier config file, eslint config file, also generated a .husky folder with the pre-commit file, and also the package.json were affected to complete the procedure(If i get your last question right) @rohitmalhotra1420

[rohitmalhotra1420]

Let's merge this after resolving the merge conflicts.