Stricter validation of return value from a rule's `create()` function
See original GitHub issueCurrent behavior
ESLint currently allows objects, arrays, functions, and literal values to be returned by a rule’s create()
function. I suspect it’s unintentional that we allow anything but objects right now.
Rule visitor functions should be defined in a returned object. For someone wanting to bail out of a rule early, the current convention is to return an empty object:
module.exports = {
meta: {
// ...
},
create(context) {
if (foo) {
// bail out since rule doesn't apply
return {};
}
return {
BlockStatement(node) {},
};
}
};
Proposed behavior
Require the return value from a rule’s create()
function to be one of the following:
Return Value | Description | Current Behavior | New Behavior |
---|---|---|---|
{ /* visitors */ } |
standard object of visitor functions | Rule executes | No change |
{} |
empty object used for bailing out early | Rule no-ops | No change |
null / undefined |
Exception (see below) | I think it would actually be useful to allow these as a means to bail out early as they could be considered a more elegant way to signal no-op behavior vs. returning an empty object (note: this is an optional part of this proposal but could be omitted in favor of only allowing empty objects for this purpose) | |
All other data types (arrays / functions / literal values, etc) | Rule no-ops | Exception (see below) |
Here’s the exception referenced in the table:
Error: The create() function for rule my-rule did not return an object.
Occurred while linting file.js
Links
_Originally posted by @bmish in https://github.com/eslint/eslint/pull/16075#discussion_r912190791_
See more context in https://github.com/eslint/eslint/pull/16075 where I added some messaging around this when the wrong return type is provided.
Issue Analytics
- State:
- Created a year ago
- Reactions:2
- Comments:10 (9 by maintainers)
Top Results From Across the Web
Should I validate a method call's return value even if I know ...
It seems there's two things you can validate: (1) That the method works properly, as in, it has no bugs. (2) That the...
Read more >Chapter 3. Declaring and validating method constraints
In the remainder of this chapter you will learn how to declare parameter and return value constraints and how to validate them using...
Read more >Bean Validation specification
Bean Validation defines rules for applying constraint annotations in ... The message element value is used to create the error message.
Read more >java - Return optional value, depending on exception thrown ...
Existing code base in my team relies on the wrapping exception mechanism - I cannot really play with it. I have encountered problems...
Read more >Using constraints on constructor and method return values
We can validate method return value to make sure that all post condition are met after calling the method. package com.logicbig.example; ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
My thoughts:
undefined
- this could indicate a bug, in particular forgetting to return visitors in some code paths or at all. I think the current behavior is more useful than acceptingundefined
and silently doing nothing.null
- this is less likely to be a bug, so it might be an alternative way to say that there are no visitors, but I’d still keep this simple and allow only a single wayreturn {}
.Oops! It looks like we lost track of this issue. What do we want to do here? This issue will auto-close in 7 days without an update.