Update: rule no-console should ignore assignment.

[aladdin-add]

What is the purpose of this pull request? (put an "X" next to item)

[x] Changes an existing rule (template)

What changes did you make? (Give an overview)
fixes #7806

Is there anything you'd like reviewers to focus on?

[eslintbot]

LGTM

[platinumazure]

Are you sure you have the correct issue number?

[aladdin-add]

@platinumazure corrected.

[platinumazure]

I think we should only avoid reporting if console.log (etc.) are on the left-hand side of an AssignmentExpression.

In other words, this should be an invalid test:

const foo = console.log;

But with this proposed implementation, I believe it will be considered valid.

[eslintbot]

LGTM

[eslintbot]

LGTM

[eslintbot]

LGTM

[eslintbot]

LGTM

[eslintbot]

LGTM

[platinumazure]

LGTM, thanks for contributing!

[not-an-aardvark]

This will still report things like

[console.log] = [0];

({ foo: console.log } = { foo: 1 });

for (console.log in { a: 1, b: 2, c: 3 });

Based on #7806 (comment), would it be better to just disallow calls to console.log(), rather than adding a few special exceptions for reassignment? For example, this PR won't solve the use case from #7806 (comment).

[eslintbot]

LGTM

[aladdin-add]

I'm 👍 to @not-an-aardvark . so I modified the implement.

if there is a consensus to change, please let me know.

[eslintbot]

LGTM

[not-an-aardvark]

Thanks! This mostly looks good, I just found a small issue.

[not-an-aardvark]

This will report errors when console.log is an argument:

foo(console.log);

Based on #7806 (comment) I think that should not report an error.

This could be fixed by doing something like:

-    .filter(item => item.identifier.parent.parent.type === "CallExpression")
+    .filter(item => item.identifier.parent.parent.type === "CallExpression" && item.identifier.parent === item.identifier.parent.parent.callee)

[not-an-aardvark]

@platinumazure I added the "needs bikeshedding" label in response to #7806 (comment), but feel free to remove it and/or relabel the PR if you're no longer in favor of this at all.

[eslintbot]

LGTM

[eslintbot]

LGTM

[not-an-aardvark]

LGTM, thanks!

[not-an-aardvark]

Waiting to merge this until the discussion in #7806 (comment) is resolved. Personally I'm fine with the semantics in this PR, but we should get consensus on it before merging.

[not-an-aardvark]

In yesterday's TSC meeting, the TSC decided that we should update the documentation for no-console to specify how to use no-restricted-syntax to achieve the other behavior, rather than changing the behavior of the function by default.