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

IIFE should never be negated when it is the program completion value #628

Closed
mpcref opened this issue Jan 30, 2015 · 5 comments · Fixed by #1522
Closed

IIFE should never be negated when it is the program completion value #628

mpcref opened this issue Jan 30, 2015 · 5 comments · Fixed by #1522

Comments

@mpcref
Copy link

mpcref commented Jan 30, 2015

See issues #625 and #627.
Two workarounds are possible to prevent the issue:
One way is to use the option negate_iife:false, the other is to prepend the IIFE with 0; combined with the option side_effects:false.
Neither of which is ideal for the overall compression.
In order to fix this bug, an IIFE should never be negated when it is the program completion value.

@rvanvelzen
Copy link
Collaborator

Could you describe a case in which it is vital to preserve program completion value?

@michaelficarra
Copy link
Contributor

What is IIFR?

@avdg
Copy link
Contributor

avdg commented Jan 30, 2015

You probably mean iife - though these shortcuts are really meaningless in my opinion...

@mpcref mpcref changed the title IIFR should never be negated when it is the program completion value IIFE should never be negated when it is the program completion value Jan 31, 2015
@mpcref
Copy link
Author

mpcref commented Jan 31, 2015

Oops, yes, I meant IFFE, my bad! Apparently, I've been overexposed these days seeing IFFR everywhere which stands for International Film Festival Rotterdam. :-)

When is the program completion value vital?

  • inlined events handlers
  • bookmarklets
  • most importantly: eval()

Or in general, when using the compressed output in any way as an expression, for instance:
new Function("return "+myCompressedScript)
Other then that, the current output is simply not an accurate representation of the input source, for what it's worth.
BTW: This change wouldn't affect output length and it wouldn't introduce compatibility issues.

@rvanvelzen
Copy link
Collaborator

Closing in favor of #640.

alexlamsl added a commit to alexlamsl/UglifyJS that referenced this issue Mar 1, 2017
Things like Angular Expression and Bookmarklet do not specify `return`, but implicitedly assumes the evaluated value from the final statement to be the return value.

fixes mishoo#354
fixes mishoo#543
fixes mishoo#625
fixes mishoo#628
fixes mishoo#640
closes mishoo#1293
alexlamsl added a commit to alexlamsl/UglifyJS that referenced this issue Mar 2, 2017
Bookmarklet for instance implicitedly assumes a "completion value" without using `return`.
The `expression` option now supports such use cases.
Optimisations on IIFEs also enhanced.

fixes mishoo#354
fixes mishoo#543
fixes mishoo#625
fixes mishoo#628
fixes mishoo#640
closes mishoo#1293
alexlamsl added a commit to alexlamsl/UglifyJS that referenced this issue Mar 3, 2017
Bookmarklet for instance implicitedly assumes a "completion value" without using `return`.
The `expression` option now supports such use cases.
Optimisations on IIFEs also enhanced.

fixes mishoo#354
fixes mishoo#543
fixes mishoo#625
fixes mishoo#628
fixes mishoo#640
closes mishoo#1293
alexlamsl added a commit that referenced this issue Mar 3, 2017
Bookmarklet for instance implicitedly assumes a "completion value" without using `return`.
The `expression` option now supports such use cases.
Optimisations on IIFEs also enhanced.

fixes #354
fixes #543
fixes #625
fixes #628
fixes #640
closes #1293
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

Successfully merging a pull request may close this issue.

4 participants