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

Rule proposal: prefer-error-iserror #723

Open
papb opened this issue May 9, 2020 · 18 comments
Open

Rule proposal: prefer-error-iserror #723

papb opened this issue May 9, 2020 · 18 comments

Comments

@papb
Copy link

papb commented May 9, 2020

Disallow instanceof Error checks.

Fail

const isError = foo instanceof Error;

Pass

const isError = Object.prototype.toString.call(foo) === '[object Error]'
@fisker
Copy link
Collaborator

fisker commented May 9, 2020

How about no-instanceof?

@sindresorhus
Copy link
Owner

Too general. It’s generally fine to instanceof your own types, just not built-ins.

@fisker
Copy link
Collaborator

fisker commented May 9, 2020

@sindresorhus
Copy link
Owner

Yeah, I think we should just do Error for now. Error is usually the problematic global.

@fisker
Copy link
Collaborator

fisker commented May 9, 2020

@sindresorhus
Copy link
Owner

Yes, the built-in errors too.

@fregante
Copy link
Collaborator

fregante commented May 11, 2020

Too general. It’s generally fine to instanceof your own types, just not built-ins.

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.

instanceof is never safe, it's just easy to use until you have to check something cross-realm.

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 no-instanceof and the default to Error and whatever you encounter the most often.

@sindresorhus
Copy link
Owner

Sounds good

@papb
Copy link
Author

papb commented May 11, 2020

Yes, the built-in errors too.

What would be the suggested fix for foo instanceof TypeError though?

Since Object.prototype.toString.call(new TypeError()) gives '[object Error]', I guess it would have to be

Object.prototype.toString.call(foo) === '[object Error]' && foo.name === 'TypeError'

instead?

@sindresorhus
Copy link
Owner

Correct

@tinovyatkin
Copy link

Depending on a project target, but since Node 10.0 util.types.isNativeError looks like way cleaner approach than Object.prototype.toString.call

@sindresorhus
Copy link
Owner

Cleaner, yes, but less cross-platform. We cannot know where the user intends to run their code.

@tinovyatkin
Copy link

tinovyatkin commented May 17, 2020

There is an ESLint environment setting for that.
https://eslint.org/docs/user-guide/configuring#specifying-environments

"env": {
  "browser": true,
  "node": true,
  "shared-node-browser": true
}

So, actually, yes, the user specified that.
And then, there is engines in package.json for Node and .browserslistrc for browsers.

@tinovyatkin
Copy link

Magically smart rule auto fix!

@sindresorhus sindresorhus changed the title Rule proposal: no-instanceof-error Rule proposal: no-instanceof-error May 17, 2020
@sindresorhus
Copy link
Owner

@tinovyatkin Sure, if we can reliably detect that it's node-only environment, we can suggest that one.

@sindresorhus
Copy link
Owner

This rule is accepted.

@fisker
Copy link
Collaborator

fisker commented Oct 30, 2024

Suggest hold this for Error.isError

@fregante fregante changed the title Rule proposal: no-instanceof-error Rule proposal: prefer-error-iserror Oct 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants