Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: Improve script performance and reliability #552

Conversation

hyperupcall
Copy link
Contributor

@hyperupcall hyperupcall commented Sep 22, 2023

Previously, only lefthook stuff under the current $PWD/node_modules was checked. Now, the current directory up until the Git root is checked (see try_exec function.

I did chang the formatting since it was really difficult to parse the shell script. If you want to change it back, let me know.

⚡ Summary

Optimizations:

  • Don't waste time running a subshell with git rev-parse --show-toplevel when it is not needed
  • Does not attempt to run lefthook to determine if lefthook can be run (use command -v instead)'
    • slight performance improvement
  • Use exec to run commands
    • Makes process signals more reliable (so that they are not ignored by the shell)

Note that this slightly changes the resolution algorithm. Before, it would look for ./node_modules/lefthook/bin/index.js, then ./node_modules/@evilmartians/lefthook/bin/lefthook_${osArch}_${cpuArch}/lefthook{{.Extension}}, etc. Now, it looks for ./node_modules/lefthook/bin/index.js, then ../node_modules/lefthook/bin/index.js, etc., all the way up to the git root. Once it reaches git root, then it goes back to the original $PWD and looks for ./node_modules/@evilmartians/lefthook/bin/lefthook_${osArch}_${cpuArch}/lefthook{{.Extension}}, and climbs up the directory tree for that path.

☑️ Checklist

  • Check locally
  • Add tests
  • Add documentation

@hyperupcall hyperupcall force-pushed the hyperupcall-recursive-search branch 2 times, most recently from 3c1a5d1 to 5e52c52 Compare September 22, 2023 06:01
@mrexox
Copy link
Member

mrexox commented Sep 22, 2023

Thank you for submitting a PR! I will take a look and come back in a few days.

@mrexox
Copy link
Member

mrexox commented Sep 22, 2023

Are you sure this will fix #510? In the issue they have node_modules in a subdir, not the parent dir 🤔

@hyperupcall
Copy link
Contributor Author

hyperupcall commented Sep 22, 2023

Oh oops, you're right, it doesn't fix that issue. I was having issues where the existing lefthook binary couldn't be found because I was in a subdirectory of the root git directory - and I did not read that issue carefully enough and thought it was the same problem.

I removed the reference to that issue.

@mrexox
Copy link
Member

mrexox commented Oct 4, 2023

@hyperupcall , I've just reviewed the PR one more time. I can't think of a case when we need to check parent directories to find the lefthook executable in node_modules. What do you think about removing this part? Other optimizations look good to me.

@hyperupcall hyperupcall force-pushed the hyperupcall-recursive-search branch from 5e52c52 to e9ed0a5 Compare October 14, 2023 12:37
@hyperupcall
Copy link
Contributor Author

hyperupcall commented Oct 16, 2023

@mrexox Sounds good - I have removed the recursive parent directory search. I have kept the other optimizations. Have gave everything another look and test and it's ready

@hyperupcall hyperupcall changed the title fix: Recursively search parent directories for lefthook fix: Improve script performance and reliability Oct 16, 2023
Comment on lines +25 to +27
try_exec "./node_modules/lefthook/bin/index.js" "$@"
try_exec "./node_modules/@evilmartians/lefthook/bin/lefthook_${osArch}_${cpuArch}/lefthook{{.Extension}}" "$@"
try_exec "./node_modules/@evilmartians/lefthook-installer/bin/lefthook_${osArch}_${cpuArch}/lefthook{{.Extension}}" "$@"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There was $dir variable assigned before. Since we don't check upper directories, please, add this variable

@hyperupcall
Copy link
Contributor Author

Because the original changes of this PR did not fully fix the mentioned issue, and the current diff no longer reflecting the original issue, and the length of time that has passed since creating this issue, I'm closing this PR. If needed, someone else can pick up the torch 🔥 - a fresh PR would probably be easier to review too

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants