
Lefthook: Knock your team’s code back into shape - ingve
https://evilmartians.com/chronicles/lefthook-knock-your-teams-code-back-into-shape
======
vemv
Generally I'm of the opinion that git hooks are not the right place to place
linters or formatters.

For a JVM language, it means that you'll spin up a JVM for each step (and you
can well have 15 formatters + linters in your stack).

So, the formatter better lives in a dev-only part of your codebase, so it's
always loaded, interacting with your codebase using _runtime insights_
otherwise impossible to gather, and it's easily hackable.

I've authored this kind of solution in the past. It works great, and a proper
CI pipeline (i.e. including linters) kills the other half of the problem.

------
davidjnelson
Love these kinds of tools. What is different between husky / git-staged and
this?

It’s faster and smaller?

Quite happy with husky and running tslint/tests with husky on precommit
currently. Curious what the biggest benefits are from left hook and if it’s a
pain to switch to if they are amazing benefits.

The biggest annoyance with current setup is on prem ci with Jenkins and GitHub
Enterprise and complex docker bash scripts embedded in Jenkins. It’s a pain to
get lint/test results to show up in the GitHub pull request ui. Doesn’t seem
like this tool would help make that use case faster to set up.

------
marmaduke
> Husky + lint-staged add roughly fifteen hundred dependencies to your
> node_modules

What on earth?

I used to work on a backend and sometimes had to test the front-end. The
webpack dev server required 2 gb of ram to boot. Sure we all have the latest
MBP amiright, but if you have a backend stack to up as well, the OOM killer is
right around the corner..

~~~
jchw
2GB would be nice... I got a bulky laptop with 16 GB to be able to run the
“full stack” at a previous employer. I had to upgrade it to 24 GB.

~~~
dajohnson89
i wont buy a dev machine with less than 32gb.

~~~
StavrosK
If my stack takes more than three gigabytes to run, I consider it broken and
file a bug to trim down the dependencies.

------
xfalcox
We are using it at Discourse (thanks to a PR from Lefthook team) and I love
it.

The fact that it is zero setup for every new contributor is a killer feature
IMO.

------
huntedsnark
This seems so backwards to me. Why not do it as part of your CI process where
you're not foisting unnecessary tooling on your developers local machines? The
lag involved in spinning up and running the commit hooks is noticeable and
disruptive especially if you commit often and rebase locally.

~~~
andreineculau
the article talks about pre-commit hook, but nobody stops you from running
these checks as pre-push hook. and nobody says you need to run the all the
checks that you'd normally run on CI, but just enough checks to get past the
silly errors.

for small repos, running linters and such on pre-push is great because you
definitely don't have unlimited CI agents, so a lag of 10 seconds for a "git
push" might mean you actually gain 30 minutes and not wait for an agent to be
available and you also save your team some good minutes with a silly CI job
failing with "missing whitespace".

PS: if you want to skip the pre-push hook once in a while, just run "git push
--no-verify"

~~~
webmonkeyuk
Having to wait 30 mins for a build to run sounds like the real issue here. How
would you push out an an emergency release in a timely way for example?

~~~
andreineculau
In a real emergency situation, there are all sorts of solutions to get a fix
out and fast. But that almost never happens, thus it's not something to
optimize for.

------
nullandvoid
Would be nice to have a tl;Dr for us folks on mobile - I enjoy this kind of
stuff very much but for some reason it felt like a drag getting to the point

Would be great to have seen some code examples of before/ after straight away
perhaps

Product seems neat I will look into giving it a go on my side projects

~~~
progapandist
Thank you for the feedback! I miss those beautiful days when people could read
6 paragraphs of text before getting bored, but I see your point!

There's a link to GitHub readme in paragraph one, for those who want to get
straight to the code.

~~~
nullandvoid
Being snarky to someone who is giving cc and stating how they want to give
your product a try is a sure fire way to not make me want to give it a try

~~~
progapandist
Not snarky at all, thank you for considering our product!

~~~
bigwavedave
> I miss those beautiful days when people could read 6 paragraphs of text
> without getting bored

> Not snarky at all!

This is clearly snarky; you're putting someone down by asserting they don't
have the attention span to read six paragraphs and that they'd understand if
they did. In reality, I read the whole thing and didn't actually get the point
until the very end, which has been echoed by more than a few comments here.
When offered constructive criticism to improve the presentation of a project,
it's been my experience that poking at the commenter in a condescending manner
is a great way to drive off potential users. Whether you intended it this way
or not (I believe you did, but mostly because I myself have to work hard from
being defensively aggressive) is moot- this is how it was received by each of
us who have commented on this specific thread, so be aware of this in the
future.

~~~
tanseydavid
The OP also responded: "but I see your point." Not snarky.

------
webmonkeyuk
Serious question: why would I want to use this instead of tests as part of the
CI process? Or would the use case be to use both but just get faster feedback
from Lefthook?

~~~
iadramelk
You should use both. Basically it's bad idea to push broken code to remote,
but running tests and linters on all files is too time consuming.

So you set up lefthook to run your tests and liters only on changed files
(which is fast and prevents 90% of problems), but then your code is pushed you
still run CI checks on all code to make sure that that some dependency in
unchanged files is not broken.

~~~
majkinetor
> Basically it's bad idea to push broken code to remote

This argument is void if CI is set to allow complete testing on branches along
with parallel pipelines. So I want to do something, I branch, code, and push.
Server does all the funky stuff without me having to install or understand
anything which is huge time saver. With parallel pipelines you do not even
block others with this behavior.

Things not on trunk can be broken, that is exactly one of the points we have
branches.

------
anentropic
similar: [https://pre-commit.com/](https://pre-commit.com/)

~~~
falsedan
[https://github.com/Arkweid/lefthook/wiki/Comparison-with-
oth...](https://github.com/Arkweid/lefthook/wiki/Comparison-with-other-
solutions#pre-commit)

~~~
frankish
I don't consider this a comparison given the content is one-sided and doesn't
present the cases where the alternatives are better.

This is a much newer project and I find it hard to believe that it is going to
be as mature.

~~~
falsedan
Not really worried about how 'mature' the thing that runs the scripts before I
commit is, either it works or it makes a mess of my working tree.

I do care about how opinionated and collaborative the dev behinde the tool is.

------
josteink
Ruby and JS only. That’s fairly low coverage.

This hook here will provide much better cover for your team:

[https://github.com/kvz/ochtra](https://github.com/kvz/ochtra)

Edit: Misunderstood the writing on the page, which in fairness is not very
clear on what it covers and how.

~~~
yaroslavm
Sure you've read the post? It's a Go tool with install shortcuts for Ruby and
JS. It works with everything.

~~~
ohnoesjmr
Your page is so long and so bad that I left it with the same assumption. Why
can't you just have a paragraph explaining what it is, why it's useful and
what it supports.

If I don't use any of the existing hook witchcraft, why do I have to go over
paragraphs and paragraphs of comparisons of things I am not familiar with?

------
cheesysam
The English in this sales page is terrible. There's even a misspelling of the
product name in the opening paragraph.

~~~
yaroslavm
How is an open source intro post a "sales page"?

~~~
ticmasta
Well, if they're trying to get you to switch or to adopt something new,
they're trying to sell. There's more to trading than just money for
product/service; could be attention, effort, endorsement, opinion and other
signalling factors, etc.

~~~
yaroslavm
By your definition, technically, any piece of content on the Web should be
considered a sales page—including your comment, where you'se selling your
opinion or attention. If that's the case, does it really make sense to label
something a "sales page" in a negative way?

Is there any other way to present a new FOSS project besides telling about the
upsides? Trashtalk it from the start, maybe? I don't really get it.

~~~
fhbdukfrh
Yep, that's kind of the point of upvotes or karma: You present your content
and try to get people to buy it. Not sure where you get the negative sales
page aspect though. I made no judgement on the presentation technique or
quality, just that open source or not, they are still selling something.

