Honestly with CommonJS and import/export, people don’t write IIFEs any more.
sotojuan
OvermindDL1
peerreynders
Like I couldn’t see that coming.
- Probably true in most modern code.
- AMD and CommonJS were never part of the JavaScript language - only ES6 introduced modules into ECMAScript.
- A minefield doesn’t disappear (and therefore the need for warnings around it) just because you build a safe highway right beside it - it just makes it somewhat less likely that someone tries to drive through it (i.e. the “language wart” still continues to exist. To a certain extent I’m reminded of the “
<insert your most despised Java wart here>is OK because the IDE can deal with it” mentality ). - "people don’t write IIFEs any more" is probably too general. "people don’t write IIFEs any more as part of the module pattern or to namespace" (in most modern code) is probably more accurate - which of course are the type of IIFEs that are at risk. IIFEs that establish private variables and functions will likely continue to see use - but they aren’t the IIFEs that are at risk.
- There are other ways and reasons to “combine/inject” code - sweet.js is just one example. Now off the top of my head I couldn’t imagine why a macro would include a standalone IIFE but that doesn’t rule anything out.
0
peerreynders
If anybody is looking for a more challenging ESlint standard: eslint-config-cleanjs
Highlights:
- no
thisand no classes- no
nullandundefined(implying that all functions mustreturn)- no mutation of any kind
- no variable reassignment
- no statements, only expressions (including no
if)- no CommonJS or AMD, only ES6 modules
1