Seems like there are several things getting conflated. You can run your shell script in an npm run script named, 'pre-commit' and not use lint-staged at all. lint-staged and husky are two different tools.
The temporary patron license window is kinda funny but I'm glad there are experimentation with open source funding models. After the funding drive / early access 5.x also will be licensed as MIT (according to the top of the project readme). The important thing is that we do not overreact to FUD. But this is a completely different issue than 'git-hook is the new husky'.
As for the unnecessary abstraction concern. Does husky, lefthook, overcommit, etc add value over using git-hooks directly? I would say in nearly all cases yes but each team/project should prob do what works best for them. git-hooks were not designed to be part of the collaborative workflow - .git/hooks/* are not nodes in the git DAG. Using the git-hook manager abstraction to hook into git but run scripts that are in other workflow tools and part of the versioned code helps the work flow code be more manageable, visible, and consistent.
In expressions-calculator you attempt to make git hooks collaborative with:
I understand its an opinion, but I dont think this is cleaner than husky. Also, what is this doing, forcing symlinks to scripts from a grandparent dir from outside the repo?
On one had I dig a git-hooks dir in the repo root idea. If I wanted an alternative to husky I might have a deps module that on install symlinked the scripts from git-hooks/ to .git/hooks BUT, git hooks are just hooks. Not a special classification of script, why should they have their own folder in the root? Perhaps a ci dir could have a pre-commit script that gets symlinked .... or perhaps we just use husky and be done with it.
The reason I am spending this much time replying is that the rejection of husky seems to be an over reacting to the licensing FUD which hurts us all. Rather than dog the project we should help end the funding drive early, and get an MIT GA release out.
"You can run your shell script in an npm run script named, 'pre-commit'" → yes I can but then I will not have access to only staged files and husky will lint all files in your project what is probably not something what you want. Probably you can try to create a script which will pull out all staged files but then why do not use git-hooks?
"it-hooks were not designed to be part of the collaborative workflow" → I agree in 100%, but husky 5 will also usegit-hooks under the hood, so not the best argument not to use git-hooks. git-hook is the best way to control commits and ultimately perform custom operations that I know of. If you have a better idea, how can I control commits in JS projects let me know?
"I understand its an opinion, but I dont think this is cleaner than husky. Also, what is this doing, forcing symlinks to scripts from a grandparent dir from outside the repo?" → as I mentioned in my article you do not have to use symlinks there is an alternative which I will paste below:
git config core.hooksPath ./git-hooks
And that's all, paste this line into postinstall script and this will work the same as symlink which I am using in my repository.
"If I wanted an alternative to husky I might have a deps module that on install symlinked the scripts from git-hooks/ to .git/hooks BUT, git hooks are just hooks. Not a special classification of script, why should they have their own folder in the root?" →I think that code splitting is always better than keeping everything in one file. If there is a possibility to move those hooks into a separated folder which will keep only those git-hooks rather than put everything into package.json than I think this is the way to go.
"The reason I am spending this much time replying is that the rejection of husky seems to be an over reacting to the licensing FUD which hurts us all" → I didn't say: "Do not use husky it is bad". I show an alternative to husky. I think many people don't know about the existence of git-hooks because husky + lint-staged is always the first result in the search engine if you are looking for information on controlling commits in JavaScript projects, so I wanted to shear my experience with git-hooks and show an alternative for this duo.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Seems like there are several things getting conflated. You can run your shell script in an npm run script named, 'pre-commit' and not use lint-staged at all. lint-staged and husky are two different tools.
The temporary patron license window is kinda funny but I'm glad there are experimentation with open source funding models. After the funding drive / early access 5.x also will be licensed as MIT (according to the top of the project readme). The important thing is that we do not overreact to FUD. But this is a completely different issue than 'git-hook is the new husky'.
As for the unnecessary abstraction concern. Does husky, lefthook, overcommit, etc add value over using git-hooks directly? I would say in nearly all cases yes but each team/project should prob do what works best for them. git-hooks were not designed to be part of the collaborative workflow - .git/hooks/* are not nodes in the git DAG. Using the git-hook manager abstraction to hook into git but run scripts that are in other workflow tools and part of the versioned code helps the work flow code be more manageable, visible, and consistent.
In expressions-calculator you attempt to make git hooks collaborative with:
"postinstall": "ln -s -f ../../git-hooks/pre-commit .git/hooks/pre-commit",I understand its an opinion, but I dont think this is cleaner than husky. Also, what is this doing, forcing symlinks to scripts from a grandparent dir from outside the repo?
On one had I dig a git-hooks dir in the repo root idea. If I wanted an alternative to husky I might have a deps module that on install symlinked the scripts from git-hooks/ to .git/hooks BUT, git hooks are just hooks. Not a special classification of script, why should they have their own folder in the root? Perhaps a ci dir could have a pre-commit script that gets symlinked .... or perhaps we just use husky and be done with it.
The reason I am spending this much time replying is that the rejection of husky seems to be an over reacting to the licensing FUD which hurts us all. Rather than dog the project we should help end the funding drive early, and get an MIT GA release out.
"You can run your shell script in an npm run script named, 'pre-commit'" → yes I can but then I will not have access to only staged files and
huskywill lint all files in your project what is probably not something what you want. Probably you can try to create a script which will pull out all staged files but then why do not usegit-hooks?"it-hooks were not designed to be part of the collaborative workflow" → I agree in 100%, but
husky 5will also usegit-hooksunder the hood, so not the best argument not to usegit-hooks.git-hookis the best way to control commits and ultimately perform custom operations that I know of. If you have a better idea, how can I control commits in JS projects let me know?"I understand its an opinion, but I dont think this is cleaner than husky. Also, what is this doing, forcing symlinks to scripts from a grandparent dir from outside the repo?" → as I mentioned in my article you do not have to use
symlinksthere is an alternative which I will paste below:And that's all, paste this line into
postinstallscript and this will work the same as symlink which I am using in my repository."If I wanted an alternative to husky I might have a deps module that on install symlinked the scripts from git-hooks/ to .git/hooks BUT, git hooks are just hooks. Not a special classification of script, why should they have their own folder in the root?" →I think that code splitting is always better than keeping everything in one file. If there is a possibility to move those hooks into a separated folder which will keep only those
git-hooksrather than put everything intopackage.jsonthan I think this is the way to go."The reason I am spending this much time replying is that the rejection of husky seems to be an over reacting to the licensing FUD which hurts us all" → I didn't say: "Do not use husky it is bad". I show an alternative to
husky. I think many people don't know about the existence ofgit-hooksbecausehusky+lint-stagedis always the first result in the search engine if you are looking for information on controlling commits in JavaScript projects, so I wanted to shear my experience withgit-hooksand show an alternative for this duo.