Lint staged runs linters against the temporary git file and does not allow A kind of Enter your code base!
Last year, I shared a theme – standardized chemical workflow convention submission, which mainly focuses on the following issues when submitting Code:Temporary storage areaCode format verification and submission information specification verification. It was there
lint-staged, I only know that this tool can deal with the files in the temporary storage area, but I didn’t have a deep understanding of it. At that time, there were some questions in my mind. Recently, I was free to solve them.
Git is divided into staging area and working area. If a file exists in two areas at the same time (GIT add of a file is modified again, as shown in test2.js below), the content of the local file is actually the same as that of the non staging area. According to the introduction of the version of lint staging area that lint staging will lint staging area, how can this be done?
UseSourceTreeOccasionally, the submitted code will compare the cards to get a glimpse (the unstaging file disappears and then reappears), so guess what method is used to clear the unstaging file first and then recover.
Guessing is guessing, but we still need to verify it.
lint-stagedBefore the check, the current file status will be saved, then the modification will be cleared, and then the lint task will be executed. After the execution, the file will be restored.
The key points are:How to save? How to recover?
I concluded that the process of lint staged is roughly as follows
So it’s very clear. From the figure, the above questions areRed processSection, let’s analyze the specific implementation in the process.
The process is roughly divided into four parts:
- Stashing changes
- Running linters
- Updating stash
- Restoring local changes
Let’s take a look at each step separately
Keep the scene of the crime and remove the interference
Git write tree // get indextree git add . Git write tree // get workingcopytree git read-tree $indexTree Git checkout index - AF // clear the modification of the file (test2.js not temporarily stored is cleared)
According to the above steps,
Tree objectTo save the temporary storage area directory and workspace directory, and clear the modified files in the workspace. After the operation, you can see that the modified
test2.jsIt has been cleared (as shown below).
Follow the configuration command, such as configuration
eslint test2.js test.js
If errors are detected in the previous step (running linkers), skip the next step (restoring local changes)
Git write tree // get formatedindextree
I need to make a special statement here,
If no errors are detected in the previous step (running linkers), then the
formattedIndexTreeWill be with the first step
indexTreeSimilarly, if an error is detected and the repaired file is added to the staging area, such as the configuration command is
eslint --fix , git addThen the code has been fixed,
Restoring local changes
Git read - tree $workingcopytree // first restore the workspace content, corresponding to git add in step 1 Git checkout index - AF // clear workspace changes Git read tree $formattedindextree // recover the contents of the staging area Git apply $patch // also applies to the workspace if the code is fixed
At the end of the day, it’s all about the operation of GIT objects.
- git-read-tree – Reads tree information into the index
- git-write-tree – Create a tree object from the current index
- git-checkout-index – Copy files from the index to the working tree