2

I've looked into a few libraries and it seems like they don't include the "use strict"; line on a file or function level. So if developers enable strict mode then how do we know if the library is compatible or not? There may be odd feature or browser specific issues that are not easily noticeable when strict mode is on and therefore missed until it's too late!

Mogsdad
  • 44,709
  • 21
  • 151
  • 275
DynamicDan
  • 425
  • 4
  • 12
  • See [this question](http://stackoverflow.com/questions/1335851/what-does-use-strict-do-in-javascript-and-what-is-the-reasoning-behind-it) – Beterraba Feb 12 '14 at 12:32
  • yes, I've seen this question but it's more about using it or not rather than finding out if a library supports strict mode. The general consensus is to always use strict mode but it creates a headache to have to fix third-party code that doesn't support it. Perhaps it's just a documentation issue.. the authors should have a standard in their code like // supports strict mode. – DynamicDan Feb 12 '14 at 16:17
  • 1
    When you use strict mode in your file, it only applies to the code actually written in that file. You can use functions from another library even if it wasnt written in strict mode. – Beterraba Feb 12 '14 at 16:43
  • My use case is that I'm concatenating all files together for a single js file. My only option is then either per function 'strict' statements or 1 at the top for the whole file. Per function is a waste of time and bytes and once at the top won't work if the third-party library is also not strict compliant even if I want to test my own code as being strict. – DynamicDan Feb 14 '14 at 10:42

1 Answers1

0

Of course, "use strict" can certainly be used at the top of a file of concatenated scripts (MDN), and so long as they are all strict-mode scripts, everything will be dandy: if not or there's a mix of strict/non-strict scripts, there's the possibility of errors being thrown that wouldn't normally be thrown.

The easiest way to work with it is to keep it in development and strip it out in production code: you know what things are supposed to do and have the ability to find/correct errors, so any strict-mode errors will only serve to improve your code. Once in production, strict mode really only serves to "break" your site for users with zero benefit to you unless they're savvy enough to debug and report it to you (not likely). Since strict-mode is a restricted form of javascript, relaxing your syntax is much more unlikely to cause errors than when you tightened it. (the major exception is eval which can begin "leaking" variables into the surrounding scope when strict-mode is removed).

Other than that, you can still concatenate scripts but wrap only strict-safe scripts in functions to use per-function strict mode. You don't have to do it per-atomic function in this case, just wrap the whole script(s) in a function:

(function(){
    "use strict"
    // My strict-mode script or scripts
})();

// non-strict safe scripts

It's not that many more characters when you consider that you only need to do it once and can stick all strict-mode scripts into that one function.

The disadvantage of having to explicitly export global vars out of the function is reduced, I find, by the fact that with strict-mode's aim to "never accidentally create global vars," I'm usually already specifying window for any variables I want global.

Brian North
  • 1,398
  • 1
  • 14
  • 19
  • I guess this infers that we shouldn't bother testing third party libs in strict mode because they are either production ready or not. If the authors don't use strict mode then it could be very time consuming to fix their code and submit patches. BUT your answer does provide a good option to do so if one wishes to. Not including strict mode for production makes a lot of sense. – DynamicDan Mar 06 '14 at 09:00
  • Some testing in strict mode can be usefull: it would point out instances where the library is "incidentally" introducing global vars that might cause conflict with your own - and yes, my usual course of action is not to wait for pull requests and to just stick that particular script in non-strict mode, but at least then I know better what it's doing. – Brian North Mar 06 '14 at 09:09
  • It seems to me that this answer addresses the matter for personal code, not for third party libraries. Am I missing something? – Vic Seedoubleyew Jan 10 '22 at 16:14