Ban redundant IIFEs
See original GitHub issuePlease describe what the rule should do:
Often people converting legacy script
style JS into modules keep redundant IIFEs. Write a rule to ban these.
A redundant IIFE is an IIFE where the result is not used, or the result is statically analysable.
What category of rule is this? (place an “X” next to just one item)
[ ] Enforces code style [ ] Warns about a potential error [ ] Suggests an alternate way of doing something X [ ] Other (please specify:)
Provide 2-3 code examples that this rule will warn about:
// bad
((global) => {
const foo = 3;
ham();
return 7;
})(window);
// good
const window = global;
const foo = 3;
ham();
// bad
$(((global) => {
const foo = 3;
ham();
return 7;
})(window));
// 'good'
const window = global;
const foo = 3;
ham();
$(7);
// bad
const res = ((global) => {
const foo = 3;
ham();
return 7;
})(window);
// 'good'
const window = global;
const foo = 3;
ham();
const res = 7;
// good
const res = (() => {
switch (foo) {
case 'ham': return 'spam';
case 'eggs': return 'bacon';
default: return 'sauce';
}
})();
// bad
const res = (() => {
switch (foo) {
case 'ham': return 'sauce';
case 'eggs': return 'sauce';
default: return 'sauce';
}
})();
// good
const res = 'sauce';
// bad
const res = (() => {
switch (foo) {
case 'ham': return 'sauce';
case 'eggs': return 'sauce';
default: throw new Error('invalid breakfast item');
}
})();
// good
const res = 'sauce';
switch(foo) {
case 'ham': break;
case 'eggs': break;
default: throw new Error('invalid breakfast item');
}
Why should this rule be included in ESLint (instead of a plugin)? Seems pretty handy, doesn’t depend on exotic syntax.
Issue Analytics
- State:
- Created 6 years ago
- Reactions:2
- Comments:7 (7 by maintainers)
Top Results From Across the Web
Are JavaScript iifes (Immediately-invoked function ...
My understanding of the concept is that iifes allow you to simulate a "private" scope which prevents the global scope from becoming cluttered....
Read more >Do-Expressions vs IIFEs: A Comparison · Issue #34 - GitHub
It has occurred to me that a comparison between the do expression and the currently idiomatic immediately-invoked function expression (IIFE) ...
Read more >no-floating-promises | typescript-eslint
Floating Promises can cause several issues, such as improperly sequenced operations, ignored Promise rejections, and more. This rule reports when a Promise is ......
Read more >Why it's Time to Stop Using JavaScript IIFEs | by John Au-Yeung
Now that ES6 is supported in almost all modern browsers, we should stop using IIFEs to separate variables from the outside world.
Read more >@typescript-eslint/parser | Yarn - Package Manager
eslint-plugin: [ban-types] update message to suggest object instead of ... eslint-plugin: add no-redundant-type-constituents rule (#4378 (63d051e) ...
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
I see, thanks for explaining.
Hmm, personally I’m not convinced that this rule is worth adding to core – it seems like a very user-specific preference. However, let’s see what the rest of the team thinks.
It seems like the team is not in favor of this rule, so I’m going to close this issue. However, you can always implement the rule as part of a plugin.