"use strict"; prepended blindly to scripts in the wild

Dmitry Soshnikov dmitry.soshnikov at gmail.com
Thu Sep 9 11:57:28 PDT 2010

On Thu, Sep 9, 2010 at 9:35 PM, Brendan Eich <brendan at mozilla.com> wrote:

> On Sep 9, 2010, at 10:33 AM, Dmitry Soshnikov wrote:
> On Thu, Sep 9, 2010 at 6:32 PM, Brendan Eich <brendan at mozilla.com> wrote:
>> On Sep 9, 2010, at 1:09 AM, Dmitry Soshnikov wrote:
>> > Thus the site's combined file won't be globally strict, however since a
>> lib is tested before a production release (at least I hope so ;), then the
>> lib's code should pass the strictness, and therefore, a "use strict" may be
>> even removed from the lib's file. However, if not to remove, then an empty
>> statement is enough.
>> That does not disable strict mode.
> Actually it does (since a strict mode, and the directive prologue is an
> initial statement):
> "use strict";eval=10 // strict, error
> but
> ;"use strict";eval = 10; // non-strict, OK
> Oh, I see -- that solves the problem of strict mode in the second or later
> parts of the concatenation.
> But the problem that's already come up on the web has strict mode enabled
> in the first part, which complies with strict mode, but later parts do not
> -- and there's no way to disable for them.
OK, seems I didn't catch the goal then. I though, that there is some single
"js-holy-file", which is a combination of some 3rd-party js-files (libs).
And one (the first one) of the libs uses strict mode, and other -- do not
(that causes issues in the code of later parts, 'cause the whole file
becomes strict). But that exactly I proposed -- to insert into the combined
file an /empty statement/ _before_ the first part. Thus, the whole single
(combined) file will be non-strict. Even if there are several strict
directives later (from every part) -- all of them (including the first one)
will be canceled because of this inserted empty statement at the beginning
of the file.

But repeat, there may be issues with different semantics of /this/ value in
strict and non-strict modes. So, as noted, it's just a quick workaround.

Also it won't help if a user uses dynamically loaded js-files from external
sources. So, this issue may really be the issue for users of such external


> /be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100909/0e953b2e/attachment.html>

More information about the es-discuss mailing list