Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Named function expressions exported with --export-all #155

Closed
ppissanetzky opened this issue Mar 22, 2013 · 5 comments
Closed

Named function expressions exported with --export-all #155

ppissanetzky opened this issue Mar 22, 2013 · 5 comments

Comments

@ppissanetzky
Copy link

Given this code:

var foo = {
    bar: function NO_WAY() {}
};

Running with

--wrap zoo  --export-all -b

Results in this:

(function(exports, global) {
    global["zoo"] = exports;
    var foo = {
        bar: function NO_WAY() {}
    };
    exports["foo"] = foo;
    exports["NO_WAY"] = NO_WAY;
})({}, function() {
    return this;
}());

The issue is that NO_WAY should not be exported since it is not a global symbol.

@mishoo
Copy link
Owner

mishoo commented Mar 22, 2013

The names of function expressions are leaked into the current scope, in order to comply with an Internet Explorer bug. Since the current scope in your situation is the global scope, it is assumed to be a global. Pass --screw-ie to enforce standards compliant behavior, that should fix your problem.

@mishoo mishoo closed this as completed Mar 22, 2013
@mishoo
Copy link
Owner

mishoo commented Mar 22, 2013

In fact, though that would work in IE < 9, it's a plain bug in compliant engines, they might report an error that NO_WAY is not defined. I'm considering disabling support for this old IE bug by default.

mishoo added a commit that referenced this issue Mar 22, 2013
Previously:

    Without `--screw-ie`, UglifyJS would always leak names of function
    expressions into the containing scope, as if they were function
    declarations.  That was to emulate IE<9 behavior.  Code relying on this
    IE bug would continue to work properly after mangling, although it would
    only work in IE (since other engines don't share the bug).  Sometimes
    this broke legitimage code (see #153 and #155).

    With `--screw-ie` the names would not be leaked into the current scope,
    working properly in legit cases; but still it broke legit code when
    running in IE<9 (see #24).

Currently:

    Regardless of the `--screw-ie` setting, the names will not be leaked.
    Code relying on the IE bug will not work properly after mangling.
    <evil laughter here>

    Without `--screw-ie`: a hack has been added to the mangler to avoid
    using the same name for a function expression and some other variable in
    the same scope.  This keeps legit code working, at the (negligible,
    indeed) cost of one more identifier.

    With `--screw-ie` you allow the mangler to name function expressions
    with the same identifier as another variable in scope.  After mangling
    code might break in IE<9.

Oh man, the commit message is longer than the patch.

Fix #153, #155
@ppissanetzky
Copy link
Author

Even when using --screw-ie, I see the behavior I posted above (in version 2.2.5)

@mishoo
Copy link
Owner

mishoo commented Mar 22, 2013

Ahh, right, there seems to be another bug related to this in that version... But the fix is unnecessary now, with the last commit. Can you try using the latest Git code? I don't want to push a new version to npm yet...

@ppissanetzky
Copy link
Author

Yes, with the latest from git it works fine either with or without the option. Good work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants