Improved workflow: Speedup pre-commit, sync up max line length

Is your feature request related to a problem? If yes, please describe it.

I noticed within some teams that certain formatting/rules aren’t applied that are defined in the pre-commit process. When talking to some of them I noticed that they find the pre-commit taking too long and simply go for --no-verify to speed up committing code, causing issues later on.

Describe the desired solution.

Remove the jest step to speedup pre-commit and make this part of the development sub branches CI. e.g. someone pushes code / creates PR = run tests

Provide additional context.

I also wonder why the gitlab config is part of this source code as it doesn’t run on gitlab CI

And while at it you might perhaps also fix this: https://github.com/intershop/intershop-pwa/blob/983ae82f0d609ed7c0a8fe6c477aff88ca485689/.prettierrc.json#L2 https://github.com/intershop/intershop-pwa/blob/983ae82f0d609ed7c0a8fe6c477aff88ca485689/tslint.json#L50

Either all 120 or all 140, i personally prefer 120, but as long as they’re in sync it’s fine by me.

[ismail-codinglab]

Makes sense, well thanks @jometzner @dhhyi ! I will try push for those changes internally

[dhhyi]

Hi @ismail-codinglab,

I agree with @jometzner on keeping the jest pre-commit hook as it is. If you have trouble motivating your colleagues, you can modify it for your project. Either remove it altogether or just remove the --findRelatedTests argument from jest. The latter one increases the amount of tests quite significantly if you are modifying core files. I would also encourage the people I work with to make smaller commits, that are well scoped and well defined. This helps with reviewing code and also helps when you are looking for bugs and want to find out what any previous change was originally intended to implement. That’s the way we have done it here and we don’t find that much resistance to this approach.

A complete test run should always be part of the CI anyway as some artifacts are loosely coupled and findRelatedTests won’t find them in rare cases.

We didn’t actually integrate the PR #484 you have been linking. Maybe working without --findRelatedTests but with --runInBand is a solution that works for you.