You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a great rule, but the documentation (which appears to just come from the original core rule) implies that arrow functions are preferred.
Instead, the mocha-aware rule discourages arrow functions. The reasoning totally resonates.
What I would have expected is, that the rule would behave as described by the documentation:
The following examples will not be flagged:
// arrow function callback
foo(a => a); // OK
... then, when used in combination with the allowUnboundThis rule, we could get the best of both worlds - arrow functions by default, but function expressions when this is used:
{ "allowUnboundThis": false } will flag the following examples:
foo(function() { this.a; });
foo(function() { (() => this); });
someArray.map(function(itm) { return this.doSomething(itm); }, someObject);
I tried disabling the no-mocha-arrows rule thinking that it might create a conflict, but still the --fix replaces my arrow functions with function expressions. I would expect (based on the documentation) that configuration like this:
describe('this is not used so it keeps the arrow fn', () => {
beforeEach(function () {
this.foo = true;
});
it('should keep the arrow fn', () => {
expect(true).toBe(true);
});
it('should replace the arrow fn with a function expression', function () {
expect(this.foo).toBe(true);
});
});
Does this make sense?
Thanks for the great plugin. This is not a deal-breaker, just a bit more verbose than it needs to be since arrow functions can be preserved according to the core ESLint rule.
The text was updated successfully, but these errors were encountered:
This is a great rule, but the documentation (which appears to just come from the original core rule) implies that arrow functions are preferred.
Instead, the mocha-aware rule discourages arrow functions. The reasoning totally resonates.
What I would have expected is, that the rule would behave as described by the documentation:
... then, when used in combination with the allowUnboundThis rule, we could get the best of both worlds - arrow functions by default, but function expressions when
this
is used:I tried disabling the
no-mocha-arrows
rule thinking that it might create a conflict, but still the--fix
replaces my arrow functions with function expressions. I would expect (based on the documentation) that configuration like this:...would produce results that look like this:
Does this make sense?
Thanks for the great plugin. This is not a deal-breaker, just a bit more verbose than it needs to be since arrow functions can be preserved according to the core ESLint rule.
The text was updated successfully, but these errors were encountered: