Support running Jasmine in Nashorn

[jbrisbin]

I started working on JUnit to JavaScript testing support using Java 8 and Nashorn [1]. I quickly found that Jasmine is not plug-and-play in a stock Nashorn environment. In particular, the use of window and window.onload is problematic and requires a shim.

I'll fork Jasmie itself and do the hacks but it would be nice if there was a way to support Nashorn OOTB without a browser emulator shim because the JS that I'll be testing will never see a browser (ever), so there's no point in making Jasmine think that's where it is.

[1] - https://github.com/reactor/reactor-js

[infews]

The code of Jasmine does not depend on window - we have to in order to support node.js.

Take a look at boot.js and node_boot.js. We expect that you should be able to write a Nashorn-specific boot file that accomplishes the same things for that environment.

[jbrisbin]

Just to clarify a little what I'm having trouble with:

I'm not using a node.js style module packaging. Therefore this code is blowing up:

  if (typeof module !== 'undefined' && module.exports) {
    return exports;
  } else {
    window.jasmineRequire = window.jasmineRequire || {};
    return window.jasmineRequire;
  }

IMO there shouldn't be any assumptions about how Jasmine registers itself. It would be a bit easier to configure if it used something like:

(function(scope) {
  // ...register Jasmine
})(this);

Which would evaluate in Nashorn to "register things in global scope" just like using window.

I can, of course, create a nashorn_boot.js to get around some of this but it still leaves me with the problem of how to get my scripts to see what's being registered when not using module.exports or window.

[hhelwich]

I had the same issue and resolved it in a similar way.
After this change, the file jasmine.js still works in the Browser but also in a non-browser environment (nashorn). Also the variable getJasmineRequireObj which seems to be private to the file does not leak in the global scope.

I do not understand how the boot.js file can help, because the jasmin.js file is loaded first. Am i missing something? I used the 2.0.0 release from here.

[infews]

@jbrisbin is right. That first block is in jasmine.js and thus the fail happens before boot.

It's in the function getJasmineRequireObj which returns the object on which each Jasmine object is defined. This is the right default implementation of this function - it works for browsers and Node.js - the two environments we support in core.

We should probably do something like

var getJasmineRequireObj = getJasmineRequireObj || function getJasmineRequireObj() {
  if (typeof module !== 'undefined' && module.exports) {
    return exports; // node.js support
  } else {
    window.jasmineRequire = window.jasmineRequire || {};
    return window.jasmineRequire; // browser support
  }
};

This would allow other environments to load a file before jasmine.js that defined this function. How does that sound?

[hhelwich]

Sounds good to me. Thank you!

[infews]

Here's the story in our backlog.

[eshepelyuk]

Maybe it will be useful to take a look at my post about running Jasmine on Nashorn
Testing JVM server-side JavaScript with Jasmine, Spock and Nashorn