return eval(xhr.responseText);
This has two side-effects that are not desirable (to me, at least)
and, I'm guessing, were unintentional.
First, 'this' in the eval'd text is bound to the jasmine object,
rather than the global object.
Second, all the variables in the include() function are in scope of the
eval'd text, including 'url' and 'xhr'.
I would suggest this:
jasmine._eval = function(__jasmine__) {
return (function(){eval(__jasmine__);})();
}
jasmine.include = function(url, opt_global) {
...
return jasmine._eval(xhr.responseText);
You could go as far as
return (function(){with(this){eval(__jasmine__);}})();
but that seems a bit like overkill: the only variable in scope that
the eval'd text could bind is __jasmine__ which is, presumably,
supposed to not be looked at/for anyway.
> Tho I'm not sure it's Jasmine's business to be doing file loading in
> the first place.
At first I strongly agreed, now ...
> Using eval at all has the nasty side-effect of stripping line
> numbers from stack traces.
This might be inevitable, at least the way I want to write tests. I
really want to be able to factor out helper stuff and I don't see how
I'm going to be able to use anything but sync xhr to load that stuff.
So whether Jasmine provides it or not, I think it's going to have to
be done.
I figured it'd be easy enough to just use jQuery to do the load,
keeping Jasmine lean. But jQuery is a little verbose when you do
this ... which isn't that surprising, given that this is not a normal
case ... except, perhaps, in testing.
Moreover, I realized I'd like Jasmine to do the include only once even
if multiple js's include the same file. Again, not something you'd see
in normal code, but maybe more common in test code?
So my thought is that if this is, in particular, testing related not
just generic, maybe there's an argument for it ...