class-methods-use-this documentation is unclear about how to correct the problems

What rule do you want to change?

class-methods-use-this

Does this change cause the rule to produce more or fewer warnings?

fewer warning

Please provide some example code that this change will affect:

In javascript we cannot call static methods from non-static methods, ie:

/*eslint class-methods-use-this: "error"*/
/*eslint-env es6*/
> class A {
 m(){console.log("hi")} // this shouln't warn
 n(){this.m()}
}
[Function: A]
> let a = new A()
undefined
> a.n()

because if I change it…

> class A {
 static m(){console.log("hi")}
 n(){this.m()}
}
[Function: A]
> let a = new A()
undefined
> a.n()
TypeError: this.m is not a function
    at A.n (repl:3:10)
    at repl:1:3
    at sigintHandlersWrap (vm.js:22:35)
    at sigintHandlersWrap (vm.js:73:12)
    at ContextifyScript.Script.runInThisContext (vm.js:21:12)
    at REPLServer.defaultEval (repl.js:340:29)
    at bound (domain.js:280:14)
    at REPLServer.runBound [as eval] (domain.js:293:12)
    at REPLServer.<anonymous> (repl.js:538:10)
    at emitOne (events.js:101:20)

I’m aware that as mdn states, we can call using the className or this.constructor, but this structure looks for me weird and verbose.

How will the change be implemented? (New option, new default behavior, etc.)?

I propose that this Rule should have an option to disable it if the method is being called from another method. 😄

[platinumazure]

@fega As @ljharb noted, this rule is slightly opinionated and encourages you to reduce your API surface by avoiding exposing instance methods that don’t use this.

For this rule (and any other ESLint rule), we recognize that there are times where a rule does not apply exactly 100% of the time. In those cases where a rule configuration option does not exist to control when the rule should or should not be enforced, you can always use // eslint-disable-line comments (or similar) to avoid ESLint reporting an error in specific cases where violating the rule is part of your design. So you could use one of those comments in this case if you believe the rule does not need to be followed in your particular case.

[ljharb]

Indeed; that documentation should be improved.