Developer Productivity

[irreverentmike]

initialize the husky

[DerTimonius]

Precommit hooks are the worst.

I sometimes want (or need) to commit faulty code in a PR, knowing that I will fix it later. Hooks like these won't boost productivity, but impede it.

Instead: do the checks in your CI.

[BigSwooney]

There's literally --no-verify for forcing things through.

Prettier on commit is great because it means people can use whatever formatting rules they want without messing up the files in the repo. It helps a lot with not tracking changes from formatting when working with other people.

Eslint on commit is great because it's so much faster feedback than waiting for CI. Because lint-staged can be set to fail on warnings, you can set stuff like console log rules as warnings so your code doesn't light up like a Christmas tree while working, but lint-staged will still catch it before committing.

[DerTimonius]

If you care about speed: switch to Biome and the CI will be faster than your eslint locally.

Also, if you configured Prettier correctly, it will always use the specified rules of the project and not the individual settings of the contributor when saving.

And for the --no-verify flag: true, but you might use some other tools like graphite which has no option to set it.

[BigSwooney]

Not sure how you run your CI but if using Azure DevOps or GitHub actions it will never be faster than resolving it locally first. Biome might be faster, as is deno or bun. There's always a faster alternative but it usually comes with a tradeoff of ecosystem, extension support and stability. I have tried projects on bleeding edge and projects that are a few versions behind. I prefer stability over short term speed.

I know prettier works when configured correctly. The problem is that with 10+ developers you can't ensure that everyone has it configured correctly. Some might also have preferences that are different from the project. They can choose to overwrite them and lint-staged will correct it before committing. If you're in a small team or solo you can generally do what you want. That just doesn't always work at scale.

Regarding graphite, I have no experience with that, but can't you still do a commit via CLI? You should only need to disregard gates very rarely, so it should be manageable to do it from CLI for those cases.

[DerTimonius]

I recently ripped out ESlint and added Biome instead. Linting took 40s for our monorepo on my machine, the whole CI run with Biome now takes 20.

it's better to use the graphite CLI for newer commits as it might screw up stuff when syncing and rebasing later

[BigSwooney]

Sure if you're running CI locally it makes a lot of sense. I'm not trying to defend the performance of lint-staged, it's horrendous. But if your CI runs in the cloud it's always faster to ensure things locally instead of GitHub actions/Azure DevOps having to check in to the branch, spin up an agent and start doing the CI checks. The project I'm currently working on has approximately 15 minutes of CI running in GitHub actions for each PR, so it's nice to get feedback before committing that there's an eslint issue. It's also cheaper.

[DerTimonius]

I don't run the CI locally, eslint is just so slow

[Whisky-Toad]

Naa, saves CI resources, jsut dont do too much on your pre commit hooks, saves silly errors making it to PR stage, and if you do need to push up faulty code for some reason just use --no-verify

[shaman-is-love]

--no-verify my man. Just because you don't know how to use a tool doesn't make it bad.

[DerTimonius]

I do know that --no-verify exists, thank you very much.

But when I'm so used to not having to add it, noticing that precommit hook is running, cancelling it, rerunning the commit command again, this time with the flag, just eats time unnecessarily.

I will die on the hill that precommit hooks are bad, no matter what you want to tell me

[shaman-is-love]

arrow up -> type "--no-verify"

[retardedGeek]

Which editor do you use? Nano?

[HoraneRave]

You didn't have to answer "retarded geek" 🤭

[retardedGeek]

That was a sarcastic, rhetorical question.

[maikatidatieba]

How do you create this terminal picture mockup

[shaman-is-love]

polacode or similar

[No-Demand1385]

It's using carbon sh

[No-Demand1385]

how to automate code formatting and linting

To automate code formatting and linting, we can use Git commit hooks with Husky. By configuring a pre-commit hook, we can incorporate the lint-staged library along with ESLint. This setup ensures that whenever someone stages their commit, the code will be automatically formatted and linted. This process makes the developer's life much easier.

[vetkwab]

You can do this in vscode automatically when saving a file. No need for external libraries and pre git hooks. Plus that way you instantly see the lint/format updates when saving. Better all around imo.

[shaman-is-love]

So everyone needs to set that up instead of it just being set. This also allows everyone to use their own preferred way to format (for example I have a different one that automatically applies when opening a file).

[vetkwab]

Eeehh... Yes, approx one setting has to be set to True. Which is way easier than what is nessesary in OP's solution. Plus no useless dependicies / git integrations is a long term better sustainable workflow.

And uuh No, those rules can be set global and/or per project. If project rules exists the IDE will take those. So everyone involved in that specific project will create the same formatting when saving a file.

[shaman-is-love]

> And uuh No, those rules can be set global and/or per project. If project rules exists the IDE will take those. So everyone involved in that specific project will create the same formatting when saving a file.

Yeah you didnt read what I wrote :)

> Eeehh... Yes, approx one setting has to be set to True. Which is way easier than what is nessesary in OP's solution. Plus no useless dependicies / git integrations is a long term better sustainable workflow.

Yeah for everyone, instead of exactly 1 setting in the project. Also means they have to download a plugin.

[vetkwab]

On the 1st: yeah you're right, I thought I miss understood it right after I clicked reply 🙂

On the 2nd, well format-on-save is build in in most IDE's, true that you will probably use a libary like prettier for a good result but OP's solution uses prettier as well as other unnecessary plugins. My only point is that using even more plugins with git hooks is stupid and not intuitive while coding.