chore: turn on padding-line-between-statements

[Shinigami92]

related to #1686

---

For now I only turned on { blankLine: 'always', prev: 'block-like', next: '*' }
This will add blank lines after blocks like if, for and switch
Then I executed pnpm eslint . --fix

I also sorted the @typesscript-eslint/* rules alphabetically

@faker-js/maintainers @faker-js/members Please let me know if you like this PR and if I should proceed or if we should merge this now and configure every further more strictness in separate PRs so the PR diff doesn't explode

I would like to additionally configure:

• case in switch blocks
• maybe a blank line before each block-like if somehow possible
• ...

[codecov]

Codecov Report

Merging #1691 (1973dda) into next (e296ff2) will decrease coverage by 0.00%.
The diff coverage is 98.87%.

Additional details and impacted files

@@            Coverage Diff             @@
##             next    #1691      +/-   ##
==========================================
- Coverage   99.64%   99.64%   -0.01%     
==========================================
  Files        2240     2240              
  Lines      240101   240190      +89     
  Branches     1068     1068              
==========================================
+ Hits       239242   239330      +88     
- Misses        838      839       +1     
  Partials       21       21              

Impacted Files	Coverage Δ
src/modules/internet/user-agent.ts	84.40% <50.00%> (-0.19%)	⬇️
src/faker.ts	95.11% <100.00%> (+0.03%)	⬆️
src/internal/mersenne/twister.ts	96.00% <100.00%> (+0.04%)	⬆️
src/modules/animal/index.ts	100.00% <100.00%> (ø)
src/modules/color/index.ts	99.73% <100.00%> (+<0.01%)	⬆️
src/modules/commerce/index.ts	100.00% <100.00%> (ø)
src/modules/company/index.ts	100.00% <100.00%> (ø)
src/modules/database/index.ts	100.00% <100.00%> (ø)
src/modules/datatype/index.ts	100.00% <100.00%> (ø)
src/modules/date/index.ts	99.73% <100.00%> (+<0.01%)	⬆️
... and 22 more

[ST-DDT]

From looking at the code/changes I wouldnt know how to write it according to the requested style unless I run the fix command.

[Shinigami92]

From looking at the code/changes I wouldnt know how to write it according to the requested style unless I run the fix command.

Luckily eslint reports useful error messages like Expected blank line before this statement.

[matthewmayer]

Will pnpm run format enforce this style?

[Shinigami92]

Will pnpm run format enforce this style?

No, sadly not, but eslint with --fix would do

[matthewmayer]

Suggest to wait until #1636 is done? Then that could be part of the preflight checks. At the moment there are too many different commands to remember to run before committing.

[EarthyOrange]

@Shinigami92 The "What about formatting?" linked page, from @ST-DDT 's screenshot in the linked issue, recommends configuring adding blank lines using a formatter instead of a linter. I see that this project uses the Prettier formatter; can you attempt following the recommendation and use the formatter to drive this formatting?

#1686 (comment)

[Shinigami92]

@Shinigami92 The "What about formatting?" linked page, from @ST-DDT 's screenshot in the linked issue, recommends configuring adding blank lines using a formatter instead of a linter. I see that this project uses the Prettier formatter; can you attempt following the recommendation and use the formatter to drive this formatting?

#1686 (comment)

1. Please do not write the same thing on two different places
2. => Try turn on eslint @typescript-eslint/padding-line-between-statements #1686 (comment)

[Shinigami92]

Suggest to wait until #1636 is done? Then that could be part of the preflight checks. At the moment there are too many different commands to remember to run before committing.

I will remove the on hold because of two reasons:

1. currently it looks like no one is assigned and tempted to actually implement the preflight command
2. the --fix is not a thing we have included in out scripts because it can take up to several minutes to run and therefore should only be used with caution and when needed
   therefore this PR does add nothing new to our actual workflow and is just a configuration of out lint rules

Also not that I run manually the --fix once in this PR as I know why I run it and only need to run it once, further usage of eslint will show errors in our IDEs like for every other lint error before

[matthewmayer]

Seems pretty harmless in practice. I tend to blindly accept any autocorrections suggested by prettier and eslint in VS Code so this wouldn't affect my workflow.

[xDivisionByZerox]

I have no problem with this kind of rule. It actually make the code more easy to read as a reviewer (at least for me) as I can consume the lines in chunks instead of the entire block at once.

[ejcheng]

I like this too, makes code much easier to read