- Make sure Husky runs
- Keep dependencies up-to-date on each release
- Run
bun lint
manually if there are codebase changes - Use
git push --no-verify
to skip the hook if you believe there is no codebase change git push --force
andgit rebase
commands are forbidden since they give the ability to manipulate the history- Follow YAGNI and SOLID principles
- Keep the codebase clean by removing unused stuff
src
├── app
├── assets
│ ├── css
│ └── images
├── common
│ ├── abis
│ └── consts
├── components
├── configs
├── entities
├── helpers
├── hooks
├── layouts
└── providers
Keep shared components. Not shared components go the corresponding _components
directory of each page.
We follow Google and Airbnb style guides with a little customization.
kebab-case
filenames- End filenames with the top parent name (i.e.
components/lorem.component.tsx
) - Always use TypeScript (
.ts
) unless you inevitably need JavaScript (.js
) - Use strict types; prevent
any
andunknown
wherever possible - Avoid acronyms and abbreviations (unless the abbreviation is much more widely used than the long form, such as URL or HTML)
- Use named exports everywhere, but pages
We follow Conventional Commits with the following defined types.
- All lowercase (unless the name is much more widely used)
Type | Description |
---|---|
fix | Represents bug fixes for the application |
ui | Changes the user interface / user experience |
refactor | Represents different or better implementations for the codebase |
feat | Adds new features to the application, not the codebase |
chore | Represents improvements for the codebase. We usually use this type if others don't fit |
test | Represents changes for tests |
revert | Represents a reverted commit; use the commit hash as the message |
perf | Represents SEO / performance improvements for the application |
ci | Represents changes for continuous integration / continuous delivery |
Follow this article.