object-shorthand doesn't flag named functions
See original GitHub issueWhat rule do you want to change? object-shorthand
Does this change cause the rule to produce more or fewer warnings? more
How will the change be implemented? (New option, new default behavior, etc.)?
New default behaviour for "object-shorthand": ["error", "methods"]
Please provide some example code that this change will affect:
export default {
foo: function foo () {},
bar: function baz () {}
}
What does the rule currently do for this code? Nothing, the rule passes
What will the rule do after it’s changed?
foo
should fail with “Expected method shorthand”
bar
should pass because the function name is different, but maybe have an option to fail that too?
Issue Analytics
- State:
- Created 5 years ago
- Comments:10 (7 by maintainers)
Top Results From Across the Web
Object initializer - JavaScript - MDN Web Docs - Mozilla
An object initializer is a comma-delimited list of zero or more pairs ... A shorthand notation is available, so that the keyword function...
Read more >Add lint rule to prohibit object-shorthand · Issue #739 - GitHub
This is a great solution, I'm glad you thought of it! I tested and confirmed that the newly introduced rule allowed function shorthand...
Read more >object-shorthand - ESLint - Pluggable JavaScript Linter
This rule does not flag arrow functions inside of object literals. ... ensures the property shorthand is used (where the key and variable...
Read more >Syntax error when using `get` in object property shorthand
1 It's available, but not in every runtime environment. In node.js, for example, you need to enable it with a --harmony_something flag.
Read more >A Simple Guide to JavaScript Functions - Native, Arrow and ...
Learn and understand everything necessary to build a real-world application with Javascript functions (Native, arrow, shorthand and others).
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
Apologies @g-plane, I should have been more clear. My second paragraph wasn’t directed at you in particular (it was just my general thoughts on this issue). I apologize for the miscommunication, and I also apologize for unintentionally seeming like I was assuming you had a different position.
Thanks for your interest in improving ESLint. Unfortunately, it looks like this issue didn’t get consensus from the team, so I’m closing it. We define consensus as having three 👍s from team members, as well as a team member willing to champion the proposal. This is a high bar by design – we can’t realistically accept and maintain every feature request in the long term, so we only accept feature requests which are useful enough that there is consensus among the team that they’re worth adding.
Since ESLint is pluggable and can load custom rules at runtime, the lack of consensus among the ESLint team doesn’t need to be a blocker for you using this in your project, if you’d find it useful. It just means that you would need to implement the rule yourself, rather than using a bundled rule that is packaged with ESLint.