$traceurRuntime used before its inclusion when using generators

[amitport]

tested a simple generator on nodejs (compiling using --modules=commonjs)

require('traceur/bin/traceur-runtime');

function* range(begin, end) {
    for (var i = begin; i <= end; ++i) {
        yield i;
    }
} 

the generated code was:

"use strict";
var $__0 = $traceurRuntime.initGeneratorFunction(range);
require('traceur/bin/traceur-runtime');
function range(begin, end) {
  var i;
  return $traceurRuntime.createGeneratorInstance(function($ctx) {
    while (true)
...

this throws ReferenceError: $traceurRuntime is not defined

(can bypass this by including the runtime in a pre-required file, but it is annoying when testing a single file)

[arv]

Not sure how to get around this yet. The call to $traceurRuntime.initGeneratorFunction is intentionally hoisted to the top because functions hoist and we need to do the initialization before any code has a chance to touch the function object.

[matthewrobb]

What about something like this:

"use strict";
var $__0 = function $__gen() {
  if(!$__gen.init) {
    $__0 = $traceurRuntime.initGeneratorFunction(range);
    $__0.init=true;
  }
  return $__0.apply(this, arguments);
};
require('traceur/bin/traceur-runtime');
function range(begin, end) {
  var i;
  return $traceurRuntime.createGeneratorInstance(function($ctx) {
    while (true)
...

[johnjbarton]

I don't understand the use case here. I thought compile with modules=commonjs was designed to create modules loaded by require() in a commonjs main. If you are testing a single file why not use the interpreter: ./tracuer foo.js?

[amitport]

--modules=commonsjs compiles the file without traceur adding System.register calls

(besides, I don't think that the --modules options actually matters, $traceurRuntime will be called before any statements)

[johnjbarton]

My point is that compiling is designed to create files that are concatenated with bin/traceur-runtime.

If we want to support importing the runtime, then we should support es6 import.

Or if the use-case is single file execute, we should use "interpret". We shouldn't add constraints on the compiler for this corner case in my opinion.

[amitport]

as I said, it can be mitigated, it is just an annoying unexpected behavior, but it seems to me that it should be treated as an issue (even if it is a 'low priority'/'does not worth the effort' issue)