d8dfun/claudecodeui
1
0
Fork 0
mirror of https://github.com/siteboon/claudecodeui.git synced 2026-03-11 00:47:52 +00:00
Code Issues Packages Projects Releases Wiki Activity

fix: removed docs folder

Browse Source
This commit is contained in:
Haileyesus
2026-03-10 19:04:17 +03:00
parent f61084109f
commit 377f604df2
2 changed files with 0 additions and 43 deletions
Download Patch File Download Diff File Expand all files Collapse all files

BIN
docs/lint-and-commit-setup/lint-and-commit-setup-flow-diagram.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 56 KiB

43
docs/lint-and-commit-setup/lint-and-commit-setup.md
View File

@@ -1,43 +0,0 @@
This markdown document provides explanations for how the lint and commit setup works in the project.
![alt text](lint-and-commit-setup-flow-diagram.png)
## Brief overview of git hooks
- Hooks are named for the event they intercept and use `pre-` or `post-` prefixes to indicate their timing. E.gs are: `pre-commit`, `commit-msg`(after the commit message, but before the commit is created), `pre-push`, and `post-receive` (after successful push).
- Inside any git repo, the hooks are stored in `.git/hooks` directory. The sample hooks can be activated by renaming them and removing the `.sample` extension.
## How does husky work?
- When we run `npm run prepare`, `husky install` command is executed, which creates a `.husky` directory in the root of the project and sets up the files for managing git hooks in `_` subdirectory. It also sets `git config core.hooksPath .husky` to tell git to look for hooks in the `.husky/_` directory instead of the default `.git/hooks` directory. We can override the default hooks by creating files with the same name as the hook we want to override in the `.husky` directory. For example, if we want to override the `pre-commit` hook, we can create a file named `pre-commit` in the `.husky` directory and add our custom script to it.
One e.g. commit flow is this:
```txt
git commit
-> Git notices "pre-commit" should run
-> Git looks in core.hooksPath (.husky/_)
-> Git executes .husky/_/pre-commit (The command is: . "$(dirname "$0")/h")
-> that forwards calls to Husky's (.husky/_/h) helper script
-> Husky's helper runs our real .husky/pre-commit script
```
## How commiting works in our project?
- We use a library called `lint-staged` to run linters on the staged files before committing. The configuration for `lint-staged` is defined in the `package.json` file under the `lint-staged` key. It specifies that we want to run `eslint` on all staged JavaScript and TypeScript files.
- Our current pre-commit hook is set up to run `lint-staged` command, which runs `eslint` on the staged files.
- Then, the `commit-msg` hook is set up to run `commitlint` command, which checks the commit message against the defined rules in `commitlint.config.js` file. The rules specify that the commit message should follow the conventional commit format, which includes a type, an optional scope, and a description. If the commit message does not follow the format, the commit will be rejected and an error message will be displayed.
```txt
git commit
... (the above flow happens)
-> `npx lint-staged` is executed in the pre-commit hook
-> `lint-staged` looks at the configuration in `package.json` and finds that it needs to run `eslint` on all staged JavaScript and TypeScript files
-> `eslint` runs on the staged files and checks for any linting errors
-> If there are linting errors, the commit is rejected and an error message is displayed
-> If there are no linting errors, the commit proceeds to the next step, which is the `commit-msg` hook
-> `npx commitlint --edit $1` is executed in the `commit-msg` hook
-> `commitlint` checks the commit message against the rules defined in `commitlint.config.js`
-> If the commit message does not follow the conventional commit format, the commit is rejected and an error message is displayed
-> If the commit message follows the conventional commit format, the commit is created successfully.
```