would PostToolUse be a better place to do it than pre-commit? (trigger on `"^(Edit|Write|MultiEdit)$"`)
for lint issues that are autofixable, the tool use can trigger formatting on that file and fix it right away
for type issues (ts, pyright), you can return something like `{\"hookSpecificOutput\":{\"additionalContext\":$escaped},\"continue\":true}"` to let the edit complete but let Claude know that there are errors to fix next turn
Wrote this a while ago and continues to feel relevant as I'm reviewing pull requests from newer teammates and staring at force-pushed commit trying to figure out what changed between now and when I last reviewed it
(Title in submission is the title I originally intended and submitted to freeCodeCamp. Their editor changed it to what it is now ("How to" and "keep your code reviewers happy"). I then edited it back to what I originally submitted. The editor then overrode my edit and reverted it back )
>Better support for usage without Webpack/Babel/front-end build tools
It looks like it's reasonably easy to setup run-time JSX compilation by using a service worker with babel to intercept and transpile .jsx files. I imagine the performance tradeoffs would be similar to using Vue with string templates? Could be faster actually since you could memoize/cache in the service worker
I've rarely seen a technology so eagerly embraced by both bleeding edge tech enthusiasts and also enterprise behemoths (granted, tech behemoths, but still)
Having API documentation that is guaranteed not to go out of date with your code. Having a shared standard for describing your endpoints in a machine-consumable way. Being able to automatically generate typescript types from any schema (correct me if I'm wrong but I don't think there's any tooling that would do the same for arbitrary REST APIs). Being able to get autocompletion when writing queries for free ^ Those were all things I didn't know I needed until I started using them, and like Typescript, it feels painful to go back to not having them