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: consistent RuleTester.errors property #59

Open
macklinu opened this issue May 28, 2018 · 2 comments
Open

Rule: consistent RuleTester.errors property #59

macklinu opened this issue May 28, 2018 · 2 comments

Comments

@macklinu
Copy link

When writing ESLint rule tests using RuleTester, it can be beneficial to enforce consistent usage of the errors property in this RuleTester docs screenshot:

image

For example, I usually always want to enforce errors to be an object, and I want to require that object to include the message, line, and column properties.

Thoughts on adding a rule like this? Still thinking through what the name could be and what the default options would be for this rule.

@macklinu macklinu changed the title Rule: consistent RuleTester.error properties Rule: consistent RuleTester.errors property May 28, 2018
@not-an-aardvark
Copy link
Contributor

Sure, this seems reasonable to me. I don't have any strong opinions about what the options would be like -- maybe a list of required keys in options objects? I'm open to other design suggestions too.

@macklinu
Copy link
Author

The hard part about this rule is how to configure it and what the default options are. With the addition of the messageId property, it doesn't necessarily make sense to default to requiring the user of this rule to use message vs. messageId. I figure at least one of them should be required, though, by default.

maybe a list of required keys in options objects

That's what I'm thinking for sure. I suppose there is nothing wrong with an opinionated default list of required keys, and if someone is using this rule, they can override the defaults? Not sure it'd be the best experience, but I don't see another way forward for this rule.

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

3 participants