The Function constructor is not recognized as eval or implied-eval

Tell us about your environment

• ESLint Version: 4.8.0

What parser (default, Babel-ESLint, etc.) are you using?

default

Please show your full configuration:

eslint --rule 'no-implied-eval: 2' --rule 'no-eval: 2' file.js

What did you do? Please include the actual source code causing the issue.

eval(`console.log("${location.hash}")`)
setTimeout(`console.log("${location.hash}")`)
Function(`console.log("${location.hash}")`)()

What did you expect to happen?

Function(str) should be an error

  1:1  error  eval can be harmful                                            no-eval
  2:1  error  Implied eval. Consider passing a function instead of a string  no-implied-eval
  3:1  error  Implied eval. Consider passing a function instead of a string  no-implied-eval

✖ 3 problems (3 errors, 0 warnings)

What actually happened? Please include the actual, raw output from ESLint.

Function(str) is not an error

  1:1  error  eval can be harmful                                            no-eval
  2:1  error  Implied eval. Consider passing a function instead of a string  no-implied-eval

✖ 2 problems (2 errors, 0 warnings)

[not-an-aardvark]

(Marking this issue as “works as intended” because the behavior described in the original issue is working as designed.)

I think we might want to reconsider our standards for adding rules to eslint:recommended in general. There was some discussion about no-console in https://github.com/eslint/eslint/issues/8544, and it seems like the consensus is to leave it in eslint:recommended because using console is undesirable in most applications. But it seems like we’re holding other rules to a much stricter standard. For example, we rejected adding no-template-curly-in-string to eslint:recommended for 4.0 because a deprecated jQuery plugin uses similar template syntax. It seems like it’s much more common to need to use console than to need to use that specific template syntax, so maybe we should reconsider the rules in eslint:recommended and try to apply a consistent standard to them.

[platinumazure]

Thanks for the issue link. I personally think eslint:recommended should include rules that are solid practices in the vast, vast majority of situations. Code generation is not a common use case, in my view. I’ll reply on that issue later.

On Oct 11, 2017 10:04 AM, “薛定谔的猫” [e-mail] wrote:

@platinumazure https://github.com/platinumazure seems we don’t have a consensus to add them. #8865 https://github.com/eslint/eslint/issues/8865

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/eslint/eslint/issues/9406#issuecomment-335841668, or mute the thread https://github.com/notifications/unsubscribe-auth/AARWeg1kKToUJ2M0T0y8KMHy08pTY4rsks5srNkKgaJpZM4Pzsae .