Change no-use-before-define default behaviour for functions

What rule do you want to change? no-use-before-define Does this change cause the rule to produce more or fewer warnings? This change will cause fewer amount of warnings How will the change be implemented? (New option, new default behavior, etc.)? New default behaviour - disable the no-use-before-define for functions by default, because it seems like there is no reason to have it enabled. Quote from the no-use-before-define rule page itself:

functions (boolean) - The flag which shows whether or not this rule checks function declarations. … . Function declarations are hoisted, so it’s safe. Default is true.

Why is it true then? Having private functions above public makes code less readable, and defining private functions below public ones is the idiomatic way of writing code in many languages, and it’s not only my opinion, (aand another link). Please provide some example code that this change will affect:

// named export functions declared on top to make it easy
// to discover the public API exposed by the module
export function namedPublicMethod() {
  // do things
  return privateHelperFunction();
}

// less often read private utility functions declared on the bottom of the file
function privateHelperFunction() {
  // do things
}

Code was used from the similar issue here What does the rule currently do for this code? Currently this code will produce an error, because the privateHelperFunction was used before it was declared. What will the rule do after it’s changed? It will not produce the warning anymore. Are you willing to submit a pull request to implement this change? Yep

[mdjermanovic]

It isn’t always safe. For example, this would throw on f():

f();

const a = 1;

function f() {
  return a;
}

I’d personally expect from this rule to enforce “no use before define” on everything by default, which is the actual behavior.

[nzakas]

Yeah, I don’t see us changing the default behavior on this rule, which is one of our oldest. There are plenty of options for changing how the rule behaves, including using a disable comment. If you want to create your own version, I’d suggest looking at eslint-rule-composer, which lets you run an existing rule and then filter out the messages you don’t want to see.

Thanks for the suggestion, but closing as we won’t be making this change.