Skip to content

Instantly share code, notes, and snippets.

@devinrhode2

devinrhode2/theo-hates-hooks-comments.md

Created November 10, 2022 19:37
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save devinrhode2/9d0a97668b1cbdda08786075b428732e to your computer and use it in GitHub Desktop.
Save devinrhode2/9d0a97668b1cbdda08786075b428732e to your computer and use it in GitHub Desktop.
Download ZIP
Raw
theo-hates-hooks-comments.md

in response to https://www.patreon.com/posts/worst-place-to-74324982

ci/cd pipeline stuff is not AS shareable as git hooks. Every ci provider has their own .yml flavor... But even a pre-commit hook can be too late in the process in some situations. I think it'd be really cool to:

  1. Have tests/eslint/tsc running while you develop
  2. Somehow, have your live reload/dev server "vouch" for certain changes you are staging in git 2.1 Unfortunately this may mean that dirty working directory changes needs to be stashed when you are committing, and then un-stashed when verification succeeds

13min Devin Rhode 2.2 A vscode extension could "hot stash" stuff by keeping your buffer un-touched, but changing the save state of files on disk. Could go badly if that extension has bugs, but means you don't have to worry about stashing/poping stash

12min Devin Rhode Then ci/cd just does some cheap verification of signatures or something and you are good to go. If a commit is failing, I think a git hook should add a hash tag to the end of the commit message like "#failing-tests" or "#failing-eslint", but not actually block the commit. So I agree with your core piece: prefer to not block commits. But as per usual, I like adding more tooling instead of removing tooling lol.

9min Devin Rhode Ultimately things will continue to shift left, and addressing roadblocks, like devs hating git hooks, will create enormous value. Hate git hooks? Hey, what if we didn't even have ci or code review, all code checks happen as you write the code and and we can do pre-commit code review too. Of course, e2e tests are slow, so we have yet another roadblock. Code review is more nuanced: it's not simply a roadblock, we may actually want to having some "chunking" going on, although maybe I just haven't seen good enough pair programming/maybe there's some cultural shift that should happen, that we all just don't see.

3min Devin Rhode With e2e tests, stately.ai may solve the performance stuff. If they have a dev server thing watching your state graph, they can know what parts of the e2e test suite should be re-run. And then they can slowly eat away jest tests, whch I fkn hate lol

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment