Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

no-unused-expressions makes an error for optional chaining of method calls: foo?.bar(); #12822

Closed
Frozen-byte opened this issue Jan 22, 2020 · 12 comments · Fixed by Typeform/eslint-config-typeform#8
Labels
archived due to age This issue has been archived; please open a new issue for any further discussion blocked This change can't be completed until another issue is resolved enhancement This change enhances an existing feature of ESLint rule Relates to ESLint's core rules

Comments

@Frozen-byte
Copy link

Reviving #11045 since optional chaining arrived Stage4!

I am unable to write a heads-up to the Issue itself.
This conversation has been locked and limited to collaborators.

@Frozen-byte Frozen-byte added enhancement This change enhances an existing feature of ESLint rule Relates to ESLint's core rules triage An ESLint team member will look at this issue soon labels Jan 22, 2020
@kaicataldo kaicataldo added blocked This change can't be completed until another issue is resolved and removed triage An ESLint team member will look at this issue soon labels Jan 23, 2020
@kaicataldo
Copy link
Member

We're currently blocked by estree/estree#204. Once that lands, all of the core rules will be updated to handle this syntax. Thanks for your patience!

@tom-sherman
Copy link

Slightly adjacent, what is the reason for the "no-unused-expressions" rule being matched for statements that cannot be parsed?

@kaicataldo
Copy link
Member

My guess is that the issue author is using a custom parser that can parse this. When using the default parser, this would currently be a parser error.

@Frozen-byte
Copy link
Author

Yes I am using "babel/no-unused-expressions" to get around that other issue.

@roth-j
Copy link

roth-j commented May 27, 2020

Has this issue been addressed? I am still seeing the eslint error for an unused expression when using optional chaining

class My Component {

...

  onChange = evt => {
    this.props.onChange?.(evt.target.value); // throws no-unused-expression
  }; 

  noChangeAlt = evt => {
    this.props.onChange(evt.target.value); // no eslint error but its complaining about executing a possibly undefined thing
  }

@garrettg123
Copy link

In the meantime, you can ignore with "no-unused-expressions": "off".

@kaicataldo
Copy link
Member

As mentioned above, we're still blocked by ESTree deciding on the AST spec.

@tomasklingen
Copy link

estree/estree#204 is merged! :)

@jeiea
Copy link

jeiea commented Jul 15, 2020

Any update on this? We can remove blocked label at least.

@mdjermanovic
Copy link
Member

mdjermanovic commented Jul 15, 2020

The core no-unused-expressions rule will support optional chaining per the estree specification when we release #13416 (expected to be in v7.5.0).

At that point, the rule will work well with the default parser.

However, if you're using babel-eslint, the current version of babel-eslint parser generates a different AST so the rule will probably not work well until babel-eslint releases babel/babel#11815.

Until the new babel-eslint release, you should probably use babel-eslint-plugin and babel/no-unused-expressions rule instead of the core no-unused-expressions rule.

Edit: we changed how the core no-unused-expressions rule works (please see the comment bellow), so now it can be used with babel-eslint, too.

@jeiea
Copy link

jeiea commented Aug 10, 2020

#13416 and babel/babel#11815 seems to be released. I had no issue without babel-eslint-plugin. Can we close this issue?

@mdjermanovic
Copy link
Member

Yes, I think we can close this issue.

We also changed the rule to not warn on unknown expressions when used with third-party parsers.

I can confirm now that the core no-unused-expressions rule doesn't report an error on foo?.bar(); when used with any of the following parsers: espree (default parser), babel-eslint, @babel/eslint-parser, @typescript-eslint/parser.

@eslint-deprecated eslint-deprecated bot locked and limited conversation to collaborators Feb 7, 2021
@eslint-deprecated eslint-deprecated bot added the archived due to age This issue has been archived; please open a new issue for any further discussion label Feb 7, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
archived due to age This issue has been archived; please open a new issue for any further discussion blocked This change can't be completed until another issue is resolved enhancement This change enhances an existing feature of ESLint rule Relates to ESLint's core rules
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants