Is the Immediately-Invoked Function Expression (IIFE) pattern really necessary when writing userscripts?

user_3258851 0
Viewed 1306

My question is quite similar to What is the purpose of a self executing function in javascript?, however it concerns userscripts (specifically for GreaseMonkey) instead.

I see that some userscripts are distributed with this pattern, and some are not.

Example of script with the IIFE pattern: (source)

// ==UserScript==
// (...)
// ==/UserScript==

(function(){
    // if <condition>
        document.location.href += '?sk=h_chr';
    // ...
})();

Example of script without it: (source)

// ==UserScript==
// (...)
// ==/UserScript==

window.location.href = "https://www.facebook.com/?sk=h_chr";

In addition, I also found that the "New script" template from TamperMonkey follows it, while the templates from GreaseMonkey and ViolentMonkey do not.

The question is, then, is the IIFE pattern any useful when writing userscripts?

Specially, if my script is in strict mode, and I use let instead of var. In any case, as far as I know, functions and variables defined in userscripts are not made available in the global page scope.

Thanks.

greasemonkey-4 tampermonkey userscripts ecmascript-6 javascript
2 Answers

In general, no; the IIFE pattern is seldom useful for wrapping a whole userscript (see edge cases below). That's a throwback to many years ago when some engines (briefly) did not wrap scripts by default.

In fact, if you include the obsolete @unwrap directive, the script engines will all now ignore it.

Here are some reasons to use the IIFE pattern:

  • It was the only way to enforce strict mode in old versions of Violentmonkey (2018 or earlier) for the whole script.
  • It can squelch a harmless Parsing error: 'return' outside of function warning if you use BOTH: (1) A script-wide return and (2) an external LINTer.
    Some old Greasemonkey versions would also warn about this, while still working perfectly.
  • (I thought there was a 3rd edge case. But got interrupted and can't remember what it was.)

Consider this test script:

// ==UserScript==
// @name     _Scope and Strict-Mode Demo script
// @match    https://stackoverflow.com/*
// @unwrap
// @grant    none
// ==/UserScript==
/* eslint-disable no-multi-spaces, curly */
'use strict';

if (location.pathname.includes("/users/") ) {
    console.log ("Terminating script early.");
    return;  // In external LINTers, this will cause a harmless warning.
}

var cantSeeMeInConsole      = "neener neener";
window.canSomestimesSeeMe   = "Howdy";

console.log (`In Strict mode: ${bInStrictMode() }; \`cantSeeMeInConsole\`: ${cantSeeMeInConsole}`);

function bInStrictMode () {
    var inStrict = false;
    var dummyObj = {};
    Object.defineProperty (dummyObj, 'foo', {value: "bar", writable: false } );

    try { dummyObj.foo = "fee"; }
    catch (e) { inStrict = true; }
    return inStrict;
}
  • Run on Firefox and Chrome.
  • Safari and Opera should give same results.
  • Microsoft Edge probably gives same results. (But I don't care much if it doesn't.)
  • Run using Tampermonkey, Violentmonkey, and Greasemonkey 4.

Script scoping:

In all cases, the userscript is scoped/wrapped. The page can't see code, nor variables like cantSeeMeInConsole.
Beware that script page conflicts can still occur in @grant none mode.

Script sandboxing:

Additional isolations apply, depending on: (a) the userscript engine, (b) the browser, and (c) the @grant mode.
For example, using Greasemonkey, or changing the grant mode kills the page's ability to see canSomestimesSeeMe.

Strict mode:

  • Placing 'use strict'; up top like that switches the whole userscript into strict mode.
  • Additionally, in Tampermonkey's advanced options, you can set "strict mode" to [Default/Always/Disabled] for all scripts.

In a related note, if the script does not use @run-at settings, there is no point in using $(document).ready() or its shorthand.

user_3315080

functions and variables defined in userscripts are not made available in the global page scope

This is not true.

The way userscripts work is via script injection (yes, it's basically an attack). The only way userscripts can get access to variables and functions in the page is to expose userscripts to the page - thus the page has access to the userscript.

Therefore the main reason to use an IIFE in userscripts is to avoid messing up scripts running on the page.

Some script injection system may transparently execute your userscript in an IIFE behind your back (this is what nodejs does with modules - yes, it's not a userscript system but it is an example of software that does this). In such cases you don't need to manually code the IIFE yourself. I personally don't know which extension does this and which does not so I tend to include the IIFE just to be safe.

If your code does not define any new variables or functions you also can get away with not using an IIFE because there is nothing in your code that can override existing code.

user_1677350
Related