You gotta love YT algorithm. Spent 3 days setting up a monorepo using turborepo, hell of a pain... Could you create a similar video on setting up for production for a monorepo?
I hate Husky, and we don't allow it in our shop. It just creates more friction, and you can do everything Husky does as part of your pipeline when someone sends a PR.
@@jamescbender43081 well, jetbrains products all have something like hook. i usually do it only to analyze my code, in case i left some TODOs or unused imports.
@@JanHesters Yeah, we let developers send PRs up with linting errors. Before anyone even reviews it, it will run through the CI/CD pipeline, so linting, and all tests (unit, E2E, etc.) get run automatically and have to pass before the PR can be approved, no matter how many votes it gets. We do this for a few reasons. First, I want all the long-running/resource-intensive steps to run on the server so they can run faster without blocking the developer from working on something else. This also ensures that the branch will integrate with the existing branch. The other big reason, and why we stay away from pre-commit hooks (like Husky) is that I want my developers to be able to commit (locally) frequenty, even if these commits are "work in process" commits, aka "I want to commit what I have so that if the next thing I try to do totally f's things up, I can go back to the last commit." and making them conform to a bunch of rules designed to protect the main branch causes a lot of friction, and discourages these kinds of commits. As log as the "last" commit that's part of the PR conforms to the rules, as enforced by the pipeline, I don't care what the previous commits in that PR do.
This is a rare channel, and I love the atmosphere your in.
Appreciate it!
I like shooting outside because we are inside enough as developers haha
You gotta love YT algorithm. Spent 3 days setting up a monorepo using turborepo, hell of a pain... Could you create a similar video on setting up for production for a monorepo?
Absolutely! But it will take a few months, I have a bunch of other topics planned first.
Thank you for the compliment and the suggestion! 🙏
dope style & crazy gold nuggets bro !
I have the privilege of working with the best when it comes to style 😉 Thanks!
Internationalization needs a dedicated tutorial
Will create one! 👍
Amazing video ❤
Thank you!
very very thanks
You're welcome! 🙏
Question, are the terrible shirts a requirement too?
Right into the feels! 💔😄 Wear whatever you want 😉
Programming Andrew Tate, lol no hate here bro.
I just find your approach interesting, something that is not common in this space
Thank you! I wanted to try something new haha! 🙏
I hate Husky, and we don't allow it in our shop. It just creates more friction, and you can do everything Husky does as part of your pipeline when someone sends a PR.
i use webstorm, i see no reason to use husky 😅
@@devyb-cc I've never used WebStorm, so I don't know how they compare, but I HATE the idea of Git pre-commit hooks in general.
@@jamescbender43081 well, jetbrains products all have something like hook. i usually do it only to analyze my code, in case i left some TODOs or unused imports.
Interesting!
How do you do it? Do you just run linting and type checks in CI/CD and let people push even with linting or type errors?
@@JanHesters Yeah, we let developers send PRs up with linting errors. Before anyone even reviews it, it will run through the CI/CD pipeline, so linting, and all tests (unit, E2E, etc.) get run automatically and have to pass before the PR can be approved, no matter how many votes it gets. We do this for a few reasons. First, I want all the long-running/resource-intensive steps to run on the server so they can run faster without blocking the developer from working on something else. This also ensures that the branch will integrate with the existing branch. The other big reason, and why we stay away from pre-commit hooks (like Husky) is that I want my developers to be able to commit (locally) frequenty, even if these commits are "work in process" commits, aka "I want to commit what I have so that if the next thing I try to do totally f's things up, I can go back to the last commit." and making them conform to a bunch of rules designed to protect the main branch causes a lot of friction, and discourages these kinds of commits. As log as the "last" commit that's part of the PR conforms to the rules, as enforced by the pipeline, I don't care what the previous commits in that PR do.
This video gave me a headache...
Why? 😄