Every application or package built to support IC Hack tech.
This is a gigantic single running Nuxt4 application. The 3 main frontend applications are separated under subdomain routing.
- Server (Perry) - Backend server written in Hono.
- Admin (Ferb) - The admin dashboard website that manages users, teams, announcements.
- Internal (Phineas) - The Internal Website used by hackers, volunteers, etc.
- Landing Page (Isabella) - The static landing page.
This application also contains the utility modules:
- You must read this README in full.
- Read relevant portions of the documentation.
Note
All IC Hack related systems every year are private. A public port (not fork) of the repository is allowed but all sensitive information must be deleted from all commit history.
This is the first time IC Hack tech systems will have extensive documentation. Execute bun docs:dev
to view the documentation. You can also view the API Reference for the server by running bunx serve scalar
.
Important
The documentation started authoring from 4th July 2024. The contributors will try to document this code as much as possible and encourage the future volunteers to do so as well. However, it may not be the case that everything is documented perfectly.
As a result, some or most of the pages here will be incomplete. Over time, we will do our best that it does not happen.
The tense used in the documentation will be confusing depending on the date it was written and the event that was spoken about.
No person can directly on the main branch. Hence you need to create a new branch to introduce any changes to the codebase.
- Create your branch name following the pattern "[type]/[short-description]" where type can be either of feat, fix, refactor, ci, chore, etc.
- Individual works in the short description must be separated by hyphens.
You should create a PR as soon as you create a branch.
- If the PR is not ready, create a Draft PR. This is so that others know what is being worked on and can provide some feedback before you are knee deep into the feature.
- The actual commit messages within your PR does not follow any conventional naming pattern. However, your PR title must follow
type(scope): description
format, similar to your branch name. - If any of the repo admins approve your PR and you need to need to update your branch, consider rebase to avoid making another commit for the admins to review again.
- @Who23 | Aditya Shrivastava for registration scripts and users admin page
- @Saim-Khan1 for implementing "Add to Google/Apple wallet" feature
- @invisi-splat | Bowen Zhu for working on hackspaces code.