ericmckean / traceur-compiler

Automatically exported from code.google.com/p/traceur-compiler
Apache License 2.0
0 stars 0 forks source link

Consider wrapping output #148

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Much of our output leaks renaming symbols into the top level. For instance, 
this code:

  // tmp.js
  import symbol from "tmp2.js";

  // tmp2.js
  export var symbol = "whatevs";

When compiled with:

   ./traceurc --inline-modules /tmp/tmp.js

Generates a tmp.compiled.js that contains:

  var $tmp2_js =(function() { 
    "use strict"; 
    var symbol = "whatevs"; 
    return Object.preventExtensions(Object.create(null, { symbol: { 
        get: function() { 
          return symbol; 
        }, 
        enumerable: true 
      } })); 
  }).call(this); 
  var destructuring$symbol = $tmp2_js, symbol = destructuring$symbol.symbol; 

And while "destructuring$symbol" and "$tmp2_js" aren't likely to cause 
conflicts, it certainly feels as though Traceur isn't being the world's best 
globals citizen in this respect.

It might, instead, be better to transform this into a form which encapsulates 
the code in an IFFE, perhaps using a template like: 
https://github.com/umdjs/umd/blob/master/returnExportsGlobal.js

Original issue reported on code.google.com by slightly...@google.com on 17 Oct 2012 at 9:22

GoogleCodeExporter commented 9 years ago
I don't see how we can wrap unless we also transform the code?

For example if the input code is something like this:

StatementsA
var glob = ExpressionB
StatementsC

and we wrap it we need to export the var. Something like this:

var glob;
function() {
  StatementsA
  glob = ExpressionB
  StatementsC
}.call(this);

Original comment by arv@chromium.org on 13 Nov 2012 at 9:52

GoogleCodeExporter commented 9 years ago
Better if not best: make all the temps properties of one global __traceur.

Original comment by johnjbar...@chromium.org on 13 Nov 2012 at 10:28