-
-
Notifications
You must be signed in to change notification settings - Fork 367
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
Rule proposal: prefer-error-iserror
#723
Comments
How about |
Too general. It’s generally fine to instanceof your own types, just not built-ins. |
Yeah, I think we should just do |
Yes, the built-in errors too. |
Is it though? If I load the same library in 2 realms I have the same issue. It's just that built-ins are more common.
Example document instanceof Object
// true
document.querySelector('iframe').contentWindow.document instanceof Object
// false I think if you want to add this rule it should be a configurable |
Sounds good |
What would be the suggested fix for Since Object.prototype.toString.call(foo) === '[object Error]' && foo.name === 'TypeError' instead? |
Correct |
Depending on a project target, but since Node 10.0 |
Cleaner, yes, but less cross-platform. We cannot know where the user intends to run their code. |
There is an ESLint environment setting for that. "env": {
"browser": true,
"node": true,
"shared-node-browser": true
} So, actually, yes, the user specified that. |
Magically smart rule auto fix! |
no-instanceof-error
@tinovyatkin Sure, if we can reliably detect that it's |
This rule is accepted. |
Suggest hold this for |
no-instanceof-error
prefer-error-iserror
Disallow
instanceof Error
checks.Fail
Pass
The text was updated successfully, but these errors were encountered: