question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

`padded-blocks`: Add "iife" object option

See original GitHub issue

What rule do you want to change?

padded-blocks

Does this change cause the rule to produce more or fewer warnings?

Either more or fewer warnings or no change, depending on the configuration.

How will the change be implemented? (New option, new default behavior, etc.)?

A new property to add to the option object, iife.

Please provide some example code that this change will affect:

Now these will change to produce no warnings:


/* eslint padded-blocks: ["error", { 
    "blocks": "never",
    "iife": "always"
}]*/

(() => {

requirePaddingHere();

})();

/* eslint padded-blocks: ["error", { 
    "blocks": "never",
    "iife": "always"
}]*/

(async () => {

await requirePaddingHere();

})();

/* eslint padded-blocks: ["error", { 
    "blocks": "always",
    "iife": "never"
}]*/

(() => {
preventPaddingHere();
})();

/* eslint padded-blocks: ["error", { 
    "blocks": "always",
    "iife": "never"
}]*/

(async () => {
await preventPaddingHere();
})();

Now these will change to produce new warnings:


/* eslint padded-blocks: ["error", { 
    "blocks": "always",
    "iife": "never"
}]*/

(function () {

preventPaddingHere();

})();

/* eslint padded-blocks: ["error", { 
    "blocks": "always",
    "iife": "never"
}]*/

(async function () {

preventPaddingHere();

})();

/* eslint padded-blocks: ["error", { 
    "blocks": "never",
    "iife": "always"
}]*/

(() => {
requirePaddingHere();
})();

/* eslint padded-blocks: ["error", { 
    "blocks": "never",
    "iife": "always"
}]*/

(async () => {
await requirePaddingHere();
})();

What does the rule currently do for this code?

Reports an error or fails to report an error.

What will the rule do after it’s changed?

  • If the context is an IIFE and the rule’s existing (string or blocks object) option is set to

    • “always” (the default behavior of requiring padding), AND the proposed iife option is set to “never”

      • …there will be Fewer warnings if the IIFE has no padding

      • …there will be More warnings if the IIFE has padding

    • “never” (the non-default of disallowing padding) AND the proposed iife option is set to “always”

      • …there will be Fewer warnings if the IIFE has padding

      • …there will be More warnings if the IIFE has no padding

  • Under any of these other possibilities, no changes will occur.

    • The context is not an IIFE

    • The user does not use the new iife option

    • The iife option value matches the string or blocks object option value

Are you willing to submit a pull request to implement this change?

Possibly, yes. 😃

Issue Analytics

  • State:closed
  • Created 4 years ago
  • Reactions:1
  • Comments:9 (7 by maintainers)

github_iconTop GitHub Comments

1reaction
mdjermanoviccommented, Mar 8, 2020

Thanks for all the details!

I support this 👍

So, for an IIFE in the code and the object configuration, "always"/"never" value that applies would be the value set in "iife" if it’s specified. Otherwise, the value set in "block".

If "block" also isn’t specified, then the IIFE will be ignored, like all other blocks.

It could be a bit confusing that "iife", which overrides "block", is at the same level in configuration (and would be even more confusing if someone asks to add "function"), but there is already a precedent of such configuration in the padding-lines-between-statements rule.

0reactions
eslint-deprecated[bot]commented, Apr 9, 2020

Unfortunately, it looks like there wasn’t enough interest from the team or community to implement this change. While we wish we’d be able to accommodate everyone’s requests, we do need to prioritize. We’ve found that issues failing to reach accepted status after 21 days tend to never be accepted, and as such, we close those issues. This doesn’t mean the idea isn’t interesting or useful, just that it’s not something the team can commit to.

Thanks for contributing to ESLint and we appreciate your understanding.

Read more comments on GitHub >

github_iconTop Results From Across the Web

padded-blocks - ESLint - Pluggable JavaScript Linter
This rule enforces consistent empty line padding within blocks. Options. This rule has two options, the first one can be a string option...
Read more >
More options for padded-blocks · Issue #3092 · eslint ... - GitHub
the first never says "never pad the inside of a block". it's just doing what padded-blocks does currently. Then the outer: option says...
Read more >
IIFE, Function Parameters, and Code Blocks Explained
A program is a list of instructions written for computers to execute. Unlike other object types, you can invoke a function without storing...
Read more >
Javascript IIFE block and Callback #14 - YouTube
Crack javascript Interviews #introductionJavascript Interview Questions Top 200 Questions Full Stack Interview questions on node js, react, ...
Read more >
Airbnb JavaScript Style Guide()
5.3 Use object destructuring for multiple return values, not array destructuring. jscs: disallowArrayDestructuringReturn. Why? You can add new properties ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found