padding-line-between-statements sometimes fails for functions

[LJNeon]

Tell us about your environment

• ESLint Version: 4.19.1
• Node Version: 10.4.1
• npm Version: 6.1.0

What parser (default, Babel-ESLint, etc.) are you using?
default

Please show your full configuration:

Configuration

{
  "env": {
    "es6": true,
    "node": true
  },
  "extends": "eslint:recommended",
  "rules": {
    "padding-line-between-statements": [2, {
      "blankLine": "never", "next": "*", "prev": "*"
    },
    {
      "blankLine": "always", "next": "class", "prev": "*"
    },
    {
      "blankLine": "always", "next": "return", "prev": "*"
    },
    {
      "blankLine": "always", "next": "class", "prev": "*"
    },
    {
      "blankLine": "always", "next": "for", "prev": "*"
    },
    {
      "blankLine": "always", "next": "*", "prev": "for"
    },
    {
      "blankLine": "always", "next": "if", "prev": "*"
    },
    {
      "blankLine": "always", "next": "*", "prev": "if"
    },
    {
      "blankLine": "always", "next": "throw", "prev": "*"
    },
    {
      "blankLine": "always", "next": "try", "prev": "*"
    },
    {
      "blankLine": "always", "next": "*", "prev": "try"
    },
    {
      "blankLine": "always", "next": "while", "prev": "*"
    },
    {
      "blankLine": "always", "next": "*", "prev": "while"
    },
    {
      "blankLine": "always", "next": "function", "prev": "*"
    },
    {
      "blankLine": "always", "next": "*", "prev": "function"
    },
    {
      "blankLine": "always", "next": "class", "prev": "*"
    },
    {
      "blankLine": "always", "next": "block-like", "prev": "const"
    },
    {
      "blankLine": "always", "next": "expression", "prev": "const"
    },
    {
      "blankLine": "always", "next": "function", "prev": "const"
    },
    {
      "blankLine": "always", "next": "const", "prev": "expression"
    },
    {
      "blankLine": "always", "next": "block-like", "prev": "let"
    },
    {
      "blankLine": "always", "next": "expression", "prev": "let"
    },
    {
      "blankLine": "always", "next": "function", "prev": "let"
    },
    {
      "blankLine": "always", "next": "let", "prev": "expression"
    }]
  },
  "parserOptions": {"ecmaVersion": 2018}
}

What did you do? Please include the actual source code causing the issue, as well as the command that you used to run ESLint.

// ...

function parseNumbers(parsedObj) {
  // ...
}

async function parse(bool, dir, files, file) {
  // ...
}
// this is the newline eslint wants me to remove
module.exports = {
  // ...
};

node_modules/.bin/eslint . --ext .js

What did you expect to happen?
since I explicitly stated that there should always be a new line after functions, and there's no later rule that would override it when an expression is below, it would work with the newline between the function and the expression.

What actually happened? Please include the actual, raw output from ESLint.
It asked me to remove that newline. This same problem happens in two other locations in my code.

[not-an-aardvark]

Hi, thanks for reporting an issue. Could you clarify which newline ESLint asked you to remove? It's a bit hard to tell with the information you've given since there are several blank lines in your code sample.

It would also be much appreciated if you could reduce your example to the smallest config/code combination that demonstrates the problem -- that would make it much easier to pinpoint what the bug is.

[LJNeon]

I've edited the eslint rules to remove all the other rules and to put a comment on the line eslint wants me to remove. I'm a little busy with some other things and don't have time to experiment with the smallest possible options for that rule.

[LJNeon]

is there any progress being made on this?

[LJNeon]

Could really use this being fixed, it's annoying for us to have to add a rule flag disabling this rule in our tests just for them to pass, even when we use it otherwise.

[LJNeon]

@not-an-aardvark

[not-an-aardvark]

Hi @LJNeon -- no, there hasn't been any progress made on this so far. In general, any progress will appear on the issue.

I think the bug here is that the rule doesn't apply the function type to async functions, since it's currently just checking here whether the first token of the declaration is a function token.

This will hopefully be fixed soon. Alternatively we'd be happy to review a PR if you're interested in fixing it.

[platinumazure]

Working on this.