Merge pull request #638 from globe-and-citizen/develop

Release 2.4

.env

@@ -50,4 +50,6 @@ VITE_ADVERTISE_IMPRESSION_RATE='0.001'
 VITE_LAYER8_PROXY=https://layer8proxy.net
 #DEV ENV FOR STATS API
 VITE_STATS_API_URL=https://stats-api-dev.up.railway.app/v1
+
+VITE_ESCROW_DEPLOYED_CONTRACT_ON_POLYGON_MAINET="0x9bf0e1fa0868997eEE5F62449F5Ea2ad5db5E75E"
 SERVICE_WORKER_FILE='custom-service-worker.js'

.eslintignore

@@ -3,4 +3,4 @@
 /src-cordova
 /.quasar
 /node_modules
-.eslintrc.js
+/.eslintrc.js

.eslintrc.js

@@ -5,7 +5,8 @@ module.exports = {
   root: true,
 
   parserOptions: {
-    ecmaVersion: '2021' // Allows for the parsing of modern ECMAScript features
+    // Allows for the parsing of modern ECMAScript features
+    ecmaVersion: '2021'
   },
 
   env: {
@@ -31,7 +32,8 @@ module.exports = {
     // Uncomment any of the lines below to choose desired strictness,
     // but leave only one uncommented!
     // See https://eslint.vuejs.org/rules/#available-rules
-    'plugin:vue/vue3-essential', // Priority A: Essential (Error Prevention)
+    // Priority A: Essential (Error Prevention)
+    'plugin:vue/vue3-essential',
     // 'plugin:vue/vue3-strongly-recommended', // Priority B: Strongly Recommended (Improving Readability)
     // 'plugin:vue/vue3-recommended', // Priority C: Recommended (Minimizing Arbitrary Choices and Cognitive Overhead)
 
@@ -43,14 +45,16 @@ module.exports = {
   plugins: [
     // https://eslint.vuejs.org/user-guide/#why-doesn-t-it-work-on-vue-files
     // required to lint *.vue files
-    'vue'
+    'vue',
+    'prettier'
     // https://github.com/typescript-eslint/typescript-eslint/issues/389#issuecomment-509292674
     // Prettier has not been included as plugin to avoid performance impact
     // add it as an extension for your IDE
   ],
 
   globals: {
-    ga: 'readonly', // Google Analytics
+    // Google Analytics
+    ga: 'readonly',
     cordova: 'readonly',
     __statics: 'readonly',
     __QUASAR_SSR__: 'readonly',
@@ -71,6 +75,18 @@ module.exports = {
     'no-empty': 'error',
     'no-inline-comments': 'error',
     'no-var': 'error',
+    'vue/no-unused-refs': 'error',
+    'vue/no-restricted-syntax': 'error',
+    'vue/no-console': 'error',
+    'vue/no-empty-component-block': 'error',
+    'vue/no-multi-spaces': 'error',
+    'vue/no-unused-emit-declarations': 'error',
+    'vue/no-unused-vars': [
+      'error',
+      {
+        ignorePattern: '^_'
+      }
+    ],
     'prefer-const': 'error'
   }
 }

.github/pull_request_template.md

@@ -1,9 +1,38 @@
-<!--
-Please, include:
-- A description of the changes proposed in the pull request.
-- A reference to a related issue in your repository:
-  - Add keyword "close", "fix" or "resolve" to inform the issue related.
-    Example: Resolve #123
--->
-
-## Description
+### 🛠 Description
+
+Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
+
+Fixes # (issue)
+
+### ✨ Type of change
+
+- [ ] Bug fix (non-breaking change which fixes an issue)
+- [ ] New feature (non-breaking change which adds functionality)
+- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
+- [ ] This change requires a documentation update
+
+### 🧠 Rationale behind the change
+
+Why did you choose to make these changes? Were there any trade-offs you had to consider?
+
+### 🧪 All Test Suites Passed?
+
+- [ ] Manual tested
+- [ ] Vitest
+- [ ] Cypress
+
+### 📸 Screenshots (optional)
+
+Please provide some screenshot for relevant changes
+
+### 🏎 Quick checklist
+
+- [ ] My code follows the style guidelines of this project
+- [ ] I have performed a self-review of my own code
+- [ ] I have commented my code, particularly in hard-to-understand areas
+- [ ] I have made corresponding changes to the documentation
+- [ ] My changes generate no new warnings
+- [ ] I have added tests that prove my fix is effective or that my feature works
+- [ ] New and existing unit tests pass locally with my changes
+- [ ] Any dependent changes have been merged and published in downstream modules
+- [ ] I have checked my code and corrected any misspellings

.gitignore

@@ -41,3 +41,6 @@ coverage/
 conf-example
 functions/node_modules
 package-lock.json
+
+package-lock.json
+

.husky/commit-msg

@@ -0,0 +1,22 @@
+#!/usr/bin/env sh
+
+message="$(cat $1)"
+requiredPattern="^(revert: )?(feat|fix|docs|dx|style|refactor|perf|test|workflow|build|ci|chore|types|wip):#\d+ - .{1,100}$"
+mergePattern="^Merge (branch|remote-tracking branch)"
+
+# Check if the commit message is a merge message
+if echo "$message" | grep -E "$mergePattern"; then
+  echo "Merge commit detected. Skipping commit message check."
+  exit 0
+fi
+
+# Check if the commit message matches the required pattern
+if ! echo "$message" | grep -E "$requiredPattern"; then
+  echo "$message"
+  echo "Error: Commit message does not match the required pattern!"
+  echo "The correct format is:"
+  echo "  <type>:#<ticketNumber> - <description>"
+  echo "Where <type> is one of: feat, fix, docs, style, refactor, test, chore."
+  echo "Example: fix:#123 - fixed issue 123"
+  exit 1
+fi

.husky/pre-commit

@@ -0,0 +1 @@
+lint-staged

CODE_OF_CONDUCT.md

@@ -1,15 +1,29 @@
-# HOW TO CONTRIBUTE
+# Code Of Conduct
 
 ## "Our World Is One Country"
 
 Globe&Citizen, as a company and service, is based on the premise that people are _people_ all around the world and that all humans display the unique capacity to cooperate flexibly in groups. Participation requires, above all else, a willingness to work with other developers who are different from yourself respectfully, openly, in good faith.
 
-## Steps to Contributing
+## Our Standards
 
-1. Fork a local copy of the code base and get to know it.
-2. Create your own development branch off of the shared "develop" branch to work on locally.
-3. Push to your forked repository and then open a 'pull' request.
+Examples of behavior that contributes to creating a positive environment include:
 
-## Other Considerations
+- Using welcoming and inclusive language
+- Being respectful of differing viewpoints and experiences
+- Gracefully accepting constructive criticism
+- Focusing on what is best for the community
+- Showing empathy towards other community members
 
-...coming soon...
+Examples of unacceptable behavior by participants include:
+
+- The use of sexualized language or imagery and unwelcome sexual attention or advances
+- Trolling, insulting/derogatory comments, and personal or political attacks
+- Public or private harassment
+- Publishing others' private information, such as a physical or electronic address, without explicit permission
+- Other conduct which could reasonably be considered inappropriate in a professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.

CONTRIBUTING.md

@@ -1,42 +1,125 @@
-# Contributing
+# Setup Instructions
 
-## Tips on Submiting Pull Requests
+### Requirements:
 
-1. When you write your Commit messages, please adhere to [CommitConventions](https://www.conventionalcommits.org/en/v1.0.0/)
-2. Before you submit a pull request, make sure that your code conforms to all of the auto stylers that we use by running the command `npm run format`:
-   - .prettierrc
-   - .eslintrc.js
-   - .editorconfig
-3. If you would like to request a code style change, you must justify your reason, provide the relevant rule for the config file and, get team approval.
-4. Be ready to do code walkthroughs for a reviewer before getting your changes merged.
-5. Other...
+- **Node.js**: v16 or higher (v20 is recommended)
+- **NPM**: v6.13.4 or higher
+- **Yarn** v1.21.1 or higher
 
-## How to run the project
+### Installation:
 
-### Fork the project to your Github account
+1. Clone the repository:
 
-1. As a contributor, you will not have immediate access to the canonical repo. Therefore, you should fork the Celebrity-Falyzer repo to your own Github account first to give you full push/pull privileges with your local copy. To get the "Develop" branch (and not just the main), be sure to uncheck the option "Fork only the 'main' branch."
-2. Globe&Citizen follows a `Main | Staging | Develop | Feature` branching structure. You will want to work off of the "Develop" branch. When you submit a Pull Request, it will be from your forked Github Repo to the branch "globe-and-citizen/develop."
+As a contributor, you will not have immediate access to the canonical repo. Therefore, you should fork the Celebrity-Falyzer repo to your own Github account first to give you full push/pull privileges with your local copy. To get the "Develop" branch (and not just the main), be sure to uncheck the option "Fork only the 'main' branch."
 
-### Install the dependencies
+```bash
+git clone https://github.com/globe-and-citizen/Celebrity-Fanalyzer.git
+cd celebrity-fanalyzer
+```
+
+2. Install dependencies
 
 ```bash
 npm install
 ```
 
-### The .env file
+3. The .env file
 
 Celebrity Fanalyzer is a serverless build using Firebase for a backend.
-
 Public development environment variables are available.
 It is not necessary to configure anything related to this.
 
-### Start the app in development mode (hot-code reloading, error reporting, etc.)
+4.  To start development with PWA support
 
 ```bash
 npm run dev
 ```
 
+5. To build the project for production
+
+```bash
+npm run build
+```
+
+# Contributing to Celebrity Fanalyzer
+
+#### _We appreciate your interest in contributing to Celebrity Fanalyzer! Please follow these guidelines to help maintain a high-quality codebase and ensure smooth collaboration._
+
+## Code standards
+
+We enforce coding standards to ensure readability, maintainability and consistency across the project. Please adhere to the following rules:
+
+<details><summary>Some common basic rules to be kept in mind to write clean code:</summary>
+
+- Use the DRY principle (Don’t repeat yourself).
+- Create multiple files instead of writing a big file. (Componentization of code: fix to small functionality for each file)
+- Place all your CSS files in one common folder.
+- Avoid Inline CSS as and when possible (a CSS class should be created when there are more than 2 CSS attributes).
+- Use a linter to make your code easier to review. Follow strict linting rules. This in turn helps you write clean, consistent code.
+- Review your code before creating a pull request.
+- Split your code into multiple smaller functions. Each with a single responsibility.
+- Create many utility files that can help you remove duplicate code from multiple files.
+- Separate all your service calls into a separate file. If it’s a big project try to split the services into multiple files. (name convention module_name.service.js).
+- Name your files logically according to the job that they perform.
+- Clean code is self-commenting(using the right variable names and function names). Use comments only to explain complex functions.
+- Always write test cases for your code. Keep tests files in sync with the files they are testing.
+- Destructuring your props is a good way to help make your coder cleaner and more maintainable.
+  For example (async function authenticate({ user_id, token }) {})
+- Putting imports in an order
+
+  - Vue imports
+  - Library imports (Alphabetical order)
+  - Absolute imports from the project (Alphabetical order)
+  - Relative imports (Alphabetical order)
+  - Import \* as
+  - Import ‘./<some file>.<some extension>
+
+  Each kind should be separated by an empty line. This makes your imports clean and easy to understand for all the components, 3rd-party libraries, and etc.
+
+</details>
+
+#### ESLint:
+
+- The project uses **ESLint** to ensure code consistency.
+- **All code must pass ESLint** before it can be commited.
+- If you need to disable any ESLint rule, justify it using comments.
+
+ESLint will run automatically on each commit.
+
+To run ESLint manually:
+
+```bash
+npm run lint
+```
+
+To let ESLint try automatically fix ESLint issues:
+
+```bash
+npm run lint:fix
+```
+
+#### Prettier:
+
+We use Prettier to format code automatically. The formatting will be checked on each commit.
+
+To format your code:
+
+```bash
+npm run format
+```
+
+## Pull Request Guidelines
+
+### What kind of Pull Requests are accepted?
+
+1. Single Responsibility Principle of a Pull Request
+2. Title and Description of a Pull Request & Pull Request Templates. You can find and use Pull Request Template in `pull_request_template.md`
+3. Comment your code, mostly in hard-to-understand areas
+4. It is the author’s duty to test the code before PR
+5. If you would like to request a code style change, you must justify your reason, provide the relevant rule for the config file and get team approval.
+6. Be ready to do code walkthroughs for a reviewer before getting your changes merged.
+7. Other...
+
 ### Good commit practices
 
 Use semantic commits like the ones described below:
@@ -75,21 +158,7 @@ Once you're done developing your updates, `git push` your changes back to your p
 Then, open a Pull Request to merge your branch into the 'develop' branch of the 'globe-and-citizen/Celebrity-Fanalyzer' repo.
 Respond and engage with feedback from the team as appropriate.
 
-## How to prettify the code
-
-### Lint the files
-
-```bash
-npm run lint
-```
-
-### Format the files
-
-```bash
-npm run format
-```
-
-## How to build and deploy your changes
+## Deployment
 
 Currently there is no need to build and deploy the application.
 After your commit and push, the build will be done automatically through a GitHub Action.