Closed kanongil closed 7 years ago
I enabled it a few days ago after @hueniverse requested it.
Because is has cost and it is more a bug than intentional.
Guess I will just have to disable the rule for my repos then.
While I agree with the sentiment, the rule is too heavy handed and prevents valid use-cases.
Eg for the following code:
exports.public = async function (something) {
if (!something) {
return false;
}
return Api.promiseReturningMethod();
}
If I want to preserve the existing implementation, I would have to create a possibly slower implementation. Either promisify the false
return value:
exports.public = function (something) {
if (!something) {
return Promise.resolve(false);
}
return Api.promiseReturningMethod();
}
or add a redundant await
:
exports.public = async function (something) {
if (!something) {
return false;
}
return await Api.promiseReturningMethod();
}
It's only true if you are working with promises directly. If you are purely in an async/await mode, it makes no difference. You just const result = await exports.public()
.
Yes, I know that it will work that way, though it requires extra documentation. I guess that is an implicit part of your await instance.method(options)
docs? Ie. theawait
keyword mean that the return value can be a Promise
, and that you never know if the method really executes sync or async.
This would be a big no-no without await
but I guess ok now, since you still have the same flow.
I guess the only real issue I have, is that I like that I can declare the method async
and know from a glance at the code, that I need to await
it. Otherwise I must go through a potentially deep chain of return values before I can come to the same conclusion.
This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.
See https://github.com/eslint/eslint/issues/6820.