Three years ago, the first contact with small program development, in fact, has just entered the Internet industry engaged in front-end development for half a year.

Husky + ESLint + Prettier + Lint-staged installation (10) Husky + ESLint + Prettier + Lint-staged installation (10) The task is performed by triggering a Git-injected pre-commit hook when the code is committed.

The configuration looked like this:

Pay attention to the command “git add” corresponding to the matching rules in “Lint-staged”. After submitted code files have formatting or specification problems have been automatically adjusted/fixed, git Add will be executed to temporarily save the modified files. Git commit -m ‘xx’ (or git commit -am ‘XXX’)

The configuration at that time was used without any problems.

Three years later, I did the small program development project again. Another colleague was mainly responsible for it, and I came to play with it (because I just entered a new company, and did not develop small program for a long time). Git commit -m ‘feat: XXX ‘, triggered the corresponding command to automatically fix esLint. After this process was complete, the code was successfully committed, but I found that other files that were not intended for this commit were also committed, resulting in no changes to the workspace.

So, I looked at his configuration:

After the command was triggered, all the files changed in the workspace were temporarily saved and submitted. Therefore, I changed it to “git add”, and then changed several files for submission test, and found the following prompt in the terminal:

I was prompted to delete this line of code because any changes made by the task are automatically added to the Git commit index, so I removed this command.

Before there was no hint, now there is such a hint, probably the version of the convenience brought by the upgrade.