Member ordering too strict

[bluong]

After using the member-ordering rule like so

"member-ordering": [true,
"public-before-private",
"static-before-instance",
"variables-before-functions"
],

It seems to inherently enact the rule that this applies to functions as well as to member variables. Can we have it so that we can only enforce this on the member variables excluding the functions?

[teamdandelion]

👍 We want this for the variables, but oftentimes we want the functions organized by functionality, e.g. a private function that supports a public part of the API, we want to group these functions together. So this rule is unusable until this is fixed.

[jbblanchet]

👍

[bluong]

Curious on the status of this

[rcollette]

+1

I should be able to put

public someProperty:any;
private _somePrivateMemberVar:any;
public someFunction = ():void => {
}
private _someFunction():void{}

Public functions/methods used as callbacks by Angular often use arrow functions. In OO terms they are methods and should not be lumped in with variable declarations.

[beuted]

+1

[jkillian]

This seems like two separate enhancements so far:

• Add an option to only enforce on variables (and not functions)
• Add an option to treat fields that are initialized as a function as if they are a function and not as a variable

Both seem like reasonable requests, but my worry is that the rule's options become overly complex.

[aciccarello]

+1 to @rcollette 's arrow function suggestion

Would that have to be a separate option or would people be okay with just considering arrow function definitions as methods?

[adidahiya]

Member variables initialized as arrow functions are now treated as methods by the member-ordering rule. Will be available in (unreleased) v3.4.0-dev.2+

[jamiewinder]

It'd be nice to opt-out of the classification of arrow functions properties as methods. Sometimes it makes more sense than others. For example, a function like this:

interface MemoizeOpts<T> {
    comparator: (a: T, b: T) => boolean;
    cacheSize?: number;
}

tslint now tells me to put the cache size above the comparator, but this doesn't make much sense as it's not as important (or even required). Just a niggle.

I can't think of anywhere I'd want to do this other than interfaces - so perhaps a way to apply this to only classes..?

[adidahiya]

@jamiewinder hmm, you're right, this part of the rule doesn't seem like it should apply to interfaces. thoughts @jkillian?

[jkillian]

@jamiewinder @adidahiya Agreed, I think we can stop treating arrow function types as methods for interfaces. Users can always use the function syntax (comparator(a: T, b: T): boolean) which is semantically the same as an arrow function type if they want it to be ordered as a method.

[jkillian]

Filed #987 to fix this

[mgol]

Member variables initialized as arrow functions are now treated as methods by the member-ordering rule. Will be available in (unreleased) v3.4.0-dev.2+

This is causing problems; see #4156.