no-unused-vars produces frequent False Positives Involving Async/Await

[Lonniebiz]

Anytime you set a variable equal to the output of an async function and then do some other work before awaiting the returned promise, eslint falsely assumes that the variable is unused, when it actually is used.

Here's the shortest example I could quickly come up with:

// esLint version 6.7.2
async function fnTest()
{
	return "Promise will resolve to this string.";
}
async function main()
{
	let usedVariable = fnTest(); // esLint thinks usedVariable is unused
	// Omitted: Do other things before awaiting usedVariable
	usedVariable = await usedVariable; // <------- Used!
}

This reminds me of a similar issue I reported 8 months ago:
#11967

[anikethsaha]

This is an intended behavior but there might need some changes with the location and the message.
It is under discussion here #13181 .

Hope it helps.

[Lonniebiz]

In async programming, the pattern of doing something else (while waiting on another thing to finish) is so common that I can't see how eslint would consider this "intended behavior".

This is a false positive, and in my coding, it is a frequently used technique that gets a lot of stuff done simultaneously (rather than waiting unnecessarily).

If this rule is not sophisticated enough to recognize such an obvious and proper use of a variable, as showcased in my example, it needs to either evolve to do so, or be omitted as a default rule, in my opinion. Otherwise, my code files are going to have more instances of /* eslint-disable no-unused-vars */ than actual code (an exaggeration to emphasize my point).

To disable this completely, would be a shame, because I am generally interested in being notified of unused variables, but not at the cost of too many false positives, like this rule currently produces.

[anikethsaha]

eslint would consider this "intended behavior".

This is my opinion, not eslint's. as I may be wrong or missing something about it.

you can use the varsIgnorePattern option in order to make it error-free.

This rule clearly focuses on whether the variable is being used (not self-reassigned) or not.
In your example above, you are not using it, you are doing self-assignment. So in a way, you don't need that variable. you can simply do await fnTest() if you are not going to do anything with the returned value.

Again, I may miss something so lets hear from others.

[Lonniebiz]

In your example above, you are not using it, you are doing self-assignment. So in a way, you don't need that variable. you can simply do await fnTest() if you are not going to do anything with the returned value.

Obviously, the example I've provided is contrived for the purpose of succinctly exemplifying the essence of the issue being reported. In practice, it is indeed the "awaited resolved promise" of usedVariable that gets used later in that vary code block. Its just that, I'm doing other work before awaiting the promise (concept: do other work while you wait). As is, you could use usedVariable 1000 times in the remainder of that same code block and eslint would still consider usedVariable unused.

I can't emphasize the obvious enough: the variable is used in the vary same written-code-block. Certainly, eslint could evolve to avoid these obvious false positives.

How can you say I'm not using that variable? On the vary line I create the variable, I set it to a promise via calling an async function. Later, I update that variable's value to the resolved promise. You say this doesn't count because it is self-reassigned. However, look on the right side of =; the "use" happens before the reassignment. Later than that, I use that resolved promise (via that same variable) as the input of functions in the same script (omitted).

Perhaps eslint should evaluate the code block first, as a whole, before allow its attention to be diverted down the promise rabbit hole. If it did, usedVariable would not be marked as unused and eslint would have a more correct understanding of reality.

I appreciate your suggestions, but I cannot appreciate your defense of false positives.

[mdjermanovic]

@Lonniebiz thanks for the issue!

I agree that we should improve this rule to show a different message and report the location of the last self-assignment, as proposed in #13181.

That being said, the provided example doesn't look like a false positive, because usedVariable isn't used after the usedVariable = await usedVariable; line.

[Lonniebiz]

Ok, I'm starting to understand what you guys are telling me.

You all are saying that the real issue is that the wrong line is being reported as unused by eslint and that anytime a reassignment isn't used, that too is "fair game" for no-unused-var, but it should be properly marked as "unused reassignment" (and the correct line should be reported instead of the one eslint is currently reporting). Yes, indeed, that is what has caused the confusion.

@anikethsaha : I finally understand what you were saying. I agree now; the real issue is #13181. Thanks for your patience.

Let this thread stand as a testament to the confusion #13181 can cause!

[mdjermanovic]

Thanks for clarifying this!

I'm closing this issue as a duplicate of #13181.