Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discussion eslint rule padding-line-between-statements #543

Open
danez opened this issue Jul 28, 2022 · 4 comments
Open

Discussion eslint rule padding-line-between-statements #543

danez opened this issue Jul 28, 2022 · 4 comments

Comments

@danez
Copy link
Contributor

danez commented Jul 28, 2022

In compute we have some styling rules that are currently not enforced, but somewhat manually requested in PRs.
These two rules are:

  1. Add an empty line before a return statement:
 something
+
 return x
  1. Add an empty line after a variable declaration, unless next statement is also a variable declaration:
 var u = 3 
 const x = 1
 let y = 2
+
 something

In zip-it-and-ship-it we enabled the rule padding-line-between-statements with the following config

    'padding-line-between-statements': [
      'error',
      // Require newline before return
      { blankLine: 'always', prev: '*', next: 'return' },
      // Require newline after a batch of variable declarations
      { blankLine: 'always', prev: ['const', 'let', 'var'], next: '*' },
      { blankLine: 'any', prev: ['const', 'let', 'var'], next: ['const', 'let', 'var'] },
    ],

and this ensures that these exact two behaviors mentioned above are enforced.

Is this something that other teams are doing as well?
Should we enable this globally in this eslint config for all nodejs projects?
Are there any reasons against doing this?

I think if we can agree on this, this is one less thing to worry about when reviewing or writing nodejs code.

I brought this up in the dev tooling guild before and now here as a concrete issue.

cc @Skn0tt @eduardoboucas @ascorbic @khendrikse @lukasholzer @netlify/netlify-dev

@eduardoboucas
Copy link
Member

My vote is yes, pretty please.

@Skn0tt
Copy link
Member

Skn0tt commented Jul 29, 2022

I mean, why not? 🤷 the less ambiguity, the better

@ascorbic
Copy link
Member

No objection here!

@khendrikse
Copy link

Sounds good!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants