feat: add oxlint linting system for frontend code to githook and add github action

.github/cliff.toml

@@ -17,6 +17,7 @@ body = """
         #### {{ group | upper_first }}
         {% for commit in commits %}
             - {{ commit.message | upper_first }}\
+            Author: {{ commit.author.name }}
         {% endfor %}
     {% endfor %}\
 {% endfor %}\n
@@ -54,8 +55,6 @@ protect_breaking_commits = false
 filter_commits = false
 # regex for matching git tags
 tag_pattern = "v[0-9].*"
-# regex for skipping tags
-skip_tags = "v0.1.0-beta.1"
 # regex for ignoring tags
 ignore_tags = ""
 # sort the tags topologically

.github/workflows/oxlint.yml

@@ -0,0 +1,14 @@
+name: Oxlint Typescript Linter
+
+on:
+  pull_request:
+  push:
+    branches: [main]
+
+jobs:
+  oxlint:
+    name: Lint JS
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v3
+      - run: npx --yes [email protected]

.github/workflows/prettier.yml

@@ -6,6 +6,13 @@ on:
     branches: [main]
 
 jobs:
+  oxlint:
+    name: Lint JS
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v3
+      - run: npx --yes [email protected]
+
   prettier:
     name: Prettier Check
     runs-on: ubuntu-latest

.husky/pre-commit

@@ -2,6 +2,6 @@
 . "$(dirname "$0")/_/husky.sh"
 
 npx lint-staged
-npx prettier -w .
+npx oxlint@latest --fix
 ./vendor/bin/pint
 python .husky/check_unstaged.py

package.json

@@ -22,6 +22,7 @@
         "husky": "^8.0.3",
         "laravel-vite-plugin": "^0.8.0",
         "lint-staged": "^15.2.0",
+        "oxlint": "^0.0.20",
         "postcss": "^8.4.18",
         "prettier": "^3.1.0",
         "react": "^18.2.0",
@@ -31,6 +32,6 @@
         "vite": "^4.0.0"
     },
     "lint-staged": {
-        "*.{js,css,md}": "prettier --write"
+        "*.{js,tsx,ts,css,md}": "prettier --write"
     }
 }

workflow.md

@@ -1,23 +1,29 @@
-New Repository Workflow
+# New Repository Workflow
+
+==========================
 
 We are transitioning to a forking workflow, wherein each team member will fork the main repository to their personal account. This approach offers several advantages,Each developer can test their changes using the CI with their personal fork, minimizing the time/$ we spend on github actions as an organization, as well as avoiding creating unnecessary noise in the CI pipeline.
 
 ### Here are the basic steps to follow:
 
-a. Fork the Repository: Start by forking the main repository to your GitHub account.
+---
+
+1. Fork the Repository: Start by forking the main repository to your GitHub account.
 
-b. Clone Your Fork: Clone your forked repository to your local machine.
+2. Clone Your Fork: Clone your forked repository to your local machine.
 
-c. Push Changes: Once your changes are ready, push them to your fork and th
+3. Push Changes: Once your changes are ready, push them to your fork and th
 
-d. Pull Request: Submit a pull request from your branch in the fork to the main repository.
+4. Pull Request: Submit a pull request from your branch in the fork to the main repository.
 
-e. Code Review and Merge: After code review, your changes will be merged into the main repository.
+5. Code Review and Merge: After code review, your changes will be merged into the main repository.
 
 This approach ensures a clean and organized development process while maintaining the integrity of the main repository.
 
 ### Conventional Commits: Guidelines and Importance
 
+---
+
 We are also introducing the use of Conventional Commits for our commit messages. Conventional Commits follow a standardized format that provides several benefits:
 
     Semantic Versioning: Conventional Commits help automate versioning by providing clear, structured commit messages that convey the nature of changes.
@@ -46,14 +52,36 @@ Conventional commit messages must be in the following format:
 
 Examples:
 
-          `feat: add password reset functionality`
+          `feat(UN-123): add password reset functionality`
 
           `fix: correct typo in login screen`
 
-          `chore: upgrade dependency version`
+          `chore: upgrade tailwind dependency version`
 
-          `refactor: remove unused variables`
+          `refactor: remove unused imports in resources`
 
           `docs: update README.md`
 
+# Please reference the `Jira` ticket in any commit that uses feat: example:
+
+```
+feat(UN-212): implement crud operations for enrollments
+```
+
+### NOTE: You do not have to do this for any other type of commit, (docs, fix, test, etc)
+
+# For commits that require you to describe or explain your changes in the PR (usually the comment block you would fill), please add these to your git commit after a newline, and it will automatically be added to the PR.
+
+**EXAMPLE:**
+
+```
+feat(UN-231): implement crud operations for enrollments
+
+enrollments controller added at `api/v1/users/{id}/enrollments`, with proper
+migrations, Model, Requests and Resource. added related foreign keys, and
+tests.
+```
+
+NOTE: If you break up those things described in the extra paragraph into individual commits themselves, and just include them all in the PR you submit, then you can skip the paragraph.
+
 The spec can be found here: https://www.conventionalcommits.org/en/v1.0.0/