Develop Reference

sharing variables in javascript ES6 without using an import statement?

I was looking for a javascript implementation of the Astar algorithm that i could steal for my own project, and google immediately led me to bgrins implementation on github:
https://github.com/bgrins/javascript-astar
I copied and pasted his astar.js, and quickly found myself confused on how i was supposed to access the code from my own js module. I took a look at his demo.js file in their repo, and quickly saw that there were no imports. demo.js immediately has access to the astar function as well as the graph object that it takes as a parameter, and i am a little confused by how they managed to accomplish this.
On line 129 of demo.js, they have
this.graph = new Graph(nodes);
without ever using an import statement.
looking closer at the top of astar.js, i see the following code:
(function (definition) {
/* global module, define */
if (typeof module === 'object' && typeof module.exports === 'object') {
module.exports = definition();
} else if (typeof define === 'function' && define.amd) {
define([], definition);
} else {
var exports = definition();
window.astar = exports.astar;
window.Graph = exports.Graph;
}
})(function () {
Clearly setting window.astar and window.Graph are a part of the answer here, but I find this whole code block a little confusing and very abstract. Can anybody help me to understand what they are doing right here?

load module in requirejs only in browser, not in nodejs

I wrote modules for both browser and nodejs using requirejs.
Everything works fine, but I want to include a module just for the browser, not for node as I don't need it and it would not work in node. (It's just a fancy design library for the browser).
My code looks like this:
define([
'requirement',
'libs/fancy'
], function(Requirement, fancy) {
// do stuff
});
fancy is the lib that I don't want in node. So I could write a workaround like this:
if (typeof window !== 'undefined') { // cheap detection of browser/node
define([
'requirement',
'libs/fancy'
], start);
} else {
define([
'requirement'
], start);
}
function start(Requirement, Fancy) {
// do stuff
}
But obviously this is ugly. Does anyone know a better way to do it?
-- EDIT 1:
var requirements = ['requirement'];
if (typeof window !== 'undefined') {
requirement.push('libs/fancy');
}
define(requirements, function(Requirement, Fancy) {
// do stuff
}
Still not perfect

I've sometimes used the second method you show of creating an array of dependencies on which I push depending on what I need.
There's another method, however, that I've used when I don't want to modify the list of dependencies. Presumably the code inside your module will have to work with an undefined value for Fancy. So you could use something like what follows. The idea is to configure RequireJS to load a module that returns an undefined value when loaded. This way you don't need to modify your dependency list. It just needs to be able to handle a case where Fancy is undefined.
var requirejs = require("requirejs");
// Create a fake module that we name immediately as "undefined".
requirejs.define("undefined", [], function () { return undefined; });
var req = requirejs.config({
map: {
// Make it so that all requests for `foo` load `undefined` instead.
"*": {
foo: "undefined"
}
}
});
req(["foo"], function (foo) {
console.log(foo);
});
The example above maps foo to undefined so when console.log executes, the value on the console is undefined. In your own code you'd map libs/fancy to undefined.
A variation on this method would be to have the undefined module return an object which shows the same interface as the real library but does nothing. This would avoid having to test whether Fancy is defined or not inside your module. I'd call the fake module something else than undefined though. Maybe something like fake-fancy.

Node.js, Mocha, make globals in closures available

I am currently setting up some mocha tests using Node and in general they work. I now came across a problem I am not able to resolve.
I have a JS file containing the following: MyClass.js
(General CoffeeScript output for class MyClass + constructor: ->)
EDIT: This is browser code, I just want to use Node to test it. (Is that even desirable?)
(function() {
window.MyClass = (function() {
function MyClass() {
// Do something cool here
}
return MyClass;
})();
}).call(this);
I now require MyClass.js in my test file. Once I run it, it directly throws an error
Testfile:
var myclass = require('MyClass.js');
...
describe('MyClass', function() { ... });
Error:
ReferenceError: window is not defined.
So far, I understand why this is happening, window does not exist in Node. But I cannot come up with a solution. I actually do not need the real window object specifically, so I thought mocking it would be enough. But it is not...
var window = {},
myclass = require('myclass.js');
...
describe('MyClass', function() { ... });
This command is also not helping: $ mocha --globals window
I still end up with the same error.
Any idea is much appreciated!

You don't actually want the window object, what you want is the global object. Here is some code that can get it in the browser (in which case it will be the same as 'window') or in node (in which case it will be the same as 'global').
var global = Function('return this')();
Then set things on that rather than on 'window'.
Note: there are other ways of getting the global object, but this has the benefit that it will work inside strict mode code too.

With following code you can use your class-like object in web-browser environment and Node.js without modification. (Sorry, I don't know how to translate that to CoffeeScript)
(function (exports) {
var MyClass = (function() {
function MyClass() {
// Do something cool here
}
return MyClass;
})();
exports(MyClass);
})(function (exported) {
if (typeof module !== 'undefined' && module.exports) {
module.exports = exported;
} else if (typeof window !== 'undefined') {
window.MyClass = exported;
} else {
throw new Error('unknown environment');
}
});
As you already have a scope which doesn't pollute global name-space, you could reduce it to:
(function (exports) {
function MyClass() {
// Do something cool here
}
exports(MyClass);
})(function (exported) {
// see above
});
I'm not an expert in AMD, require.js and other module loaders, but I think it should be easy to extend this pattern to support other environments as well.
Edit
In a comment you said that the above solution is not working when translated back to CoffeeScript. Therefore, I suggest another solution. I haven't tried it but maybe this could be a way to solve your problem:
global.window = {}; // <-- should be visible in your myclass.js
require('myclass.js');
var MyClass = global.window.MyClass;
describe('MyClass', function() {
var my = new MyClass();
...
});
It's a horrible piece of code, but if it works, maybe for testing purposes it's sufficient.
Due to the module loading behaviour of node.js this only works if your require('myclass.js') is the first require of this file in the node process. But in case of testing with Mocha this should be true.

1) What you are looking for is the module.exports to expose things in Node:
http://openmymind.net/2012/2/3/Node-Require-and-Exports/
2) Also you don't need IIFE in Node, you can drop the (function() {...
3) You can alway look at some popular Node repo on Github to see examples, look at the Mocha code since you're using it, you'll learn a thing or two.

Something like jsdom is lighter than PhantomJS and yet provides quite a few things you need to test code that expects to be running with a proper window. I've used it with great success to test code that navigates up and down the DOM tree.
You ask:
This is browser code, I just want to use Node to test it. (Is that even desirable?)
It is very desirable. There's a point at which a solution like jsdom won't cut it but as long as your code is within the limit of what jsdom handles, might as well use it and keep the cost of launching a test environment to the minimum needed.

#hgoebl: As I'm not the OP, I can not add his original CoffeeScript code, but here is my example:
pubsub.coffee:
window.PubSub = window.PubSub || {}
PubSub.subscribe = ( subject, callback )->
now the test:
assert = require "assert"
pubsub = require './pubsub.coffee'
describe "pubsub.http interface", ->
it "should perform a http request", ->
PubSub.subscribe 1, 2
what works for me up to now is:
window.PubSub = window.PubSub || {}
window.PubSub.subscribe = ( subject, callback )->
and the test:
`window = {}`
assert = require "assert"
pubsub = require './pubsub.coffee'
describe "pubsub.http interface", ->
it "should perform a http request", ->
window.PubSub.subscribe 1, 2
The main drawback of the solution, is that I have to explicitly mention the window object in the implementation and the test. User code executed in a browser should be able to omit it.
I now came up with an other solution:
window = window || exports
window.PubSub = window.PubSub || {}
PubSub = PubSub || window.PubSub
PubSub.subscribe = ( subject, callback )->
and then in the test, simply requiring the PubSub namespace:
PubSub = require( './pubsub.coffee' ).PubSub
And finally, the solution from kybernetikos applied looks like this:
global = `Function('return this')()`
global.PubSub = global.PubSub || {}
PubSub.subscribe = ( subject, callback )->
As now, the PubSub namespace is in the global namespace, just a simple require is needed in the file that contains the mocha tests:
require( './pubsub.coffee' )

Advice to resolve window dependency when running in node.js

I'm trying to extend my browser-side library's runtime environment to node.js. I implemented the Universal Module Definition (UMD) pattern to do that. It works with AMD implementation and <script> but doesn't work in node.js since there is no window.
The dependencies in question are WebSocket, EventSource, XMLHttpRequest, document. The detail is described in here: https://github.com/flowersinthesand/portal/issues/115 So what is the best approach to resolve window dependency in node.js? I have though the following way to do that. Since I'm new to node.js, these are somewhat unfamiliar and I don't know which way is natural. Though I'm trying to support node.js, I don't want to change too much something.
The following code snippet comes from https://github.com/flowersinthesand/portal/blob/master/portal.js
Using jsdom
(function(root, factory) {
if (typeof define === 'function' && define.amd) {
// AMD
define(function() {
// Passes the window
return factory(root);
});
} else if (typeof exports === 'object') {
// Node
module.exports = factory(require('jsdom').something);
} else {
// Browser globals, Window
root.portal = factory(root);
}
}(this, function(window) {
If the jsdom supports the above dependencies well, this looks best. If it works, however, I wonder why client of sockjs, socket.io and engine.io don't use jsdom. Maybe, they are for node rather than browser? performance?
Making window as a plain object of dependency
(function(root, factory) {
if (typeof define === 'function' && define.amd) {
// AMD
define(function() {
// Passes the window
return factory(root);
});
} else if (typeof exports === 'object') {
// Node
module.exports = factory({
WebSocket: require('package name for WebSocket').something,
EventSource: require('package name for EventSource').something,
document: require('jsdom').hmm,
// ...
});
} else {
// Browser globals, Window
root.portal = factory(root);
}
}(this, function(window) {
It looks picky and somewhat uncomfortable to make a group of dependency, window, But, I want to preserve current code if possible. Also, jsdom may be required as well to resolve document used to do HTTP request by script tag when XMLHttpRequest can't work due to cross-domain or unloading event and this situation includes IE 6. It's possible to separate logic using document to use something supported in node and script tag in browser checking what the current runtime is, but it's big change for me.

(function(root, factory) {
if (typeof define === "function" && define.amd) {
// AMD
define(function() {
return factory(root);
});
} else if (typeof exports === "object") {
// Node
module.exports = factory(function() {
// Prepare the window powered by jsdom
var window = require("jsdom").jsdom().createWindow();
window.WebSocket = require("ws");
window.EventSource = require("eventsource");
return window;
}());
// node-XMLHttpRequest 1.x conforms XMLHttpRequest Level 1 but can perform a cross-domain request
module.exports.support.corsable = true;
} else {
// Browser globals, Window
root.portal = factory(root);
}
}(this, function(window) {

JavaScript Modules, Closures and Scope

I am using the following closure pattern to modularise my code:
(function(root) {
// MODULE CODE HERE
if (typeof module !== 'undefined' && module.exports) { // CommonJS
/* var dependencies = require(...) */
module.exports = myModule;
} else if (typeof define !== 'undefined' && define.amd) { // AMD
/* var dependencies...; */
define([/* dependencies */], function(/* dependencies */) {
/* Assign closure level vars to respective arguments */
return myModule;
});
} else {
// Dependencies??
root.myModule = myModule;
}
})(this);
i.e., We use feature detection to support CommonJS modules (e.g., node.js), AMD or basic global namespace instantiation.
This works fine in node.js; I haven't tested the AMD pattern yet, as I'm still reading up on it (See Edit 2: AMD exhibits the exact same effect); but it fails in the browser if the module has any dependencies. That is, say, if myModule references something that is defined in a different module: For example, say if I had super.js and child.js with respective module definitions, as above, where super.js creates a function called root.super (root === window in the browser), if child.js tries to do super(), I will get something like super is not a function.
What's going on here?
To try to fix it, I changed the order in which super.js and child.js are loaded in <script> elements: No luck. Then I tried forcing child.js to load when the document is ready, using jQuery:
$(document).ready(function() {
$.getScript('child.js', function() {
// Do stuff with child, which calls super
});
});
...again, same problem. However, in both cases, if I enter the console, super is available and defined as I'm expecting.
Why is super in child.js presumably from a different (i.e., not the global) scope?
I should add, if I remove the dependency injection bit in the CommonJS export, it fails in node.js with the same error (if there are any dependants).
EDIT #Amberlamps' answer solved the problem, but it didn't answer the question as to why this occurs. My module pattern is now:
(function(root) {
// MODULE CODE HERE
if (typeof module !== 'undefined' && module.exports) { // CommonJS
/* var dependencies = require(...) */
module.exports = myModule;
} else if (typeof define !== 'undefined' && define.amd) { // AMD
/* var dependencies...; */
define([/* dependencies */], function(/* dependencies */) {
/* Assign closure level vars to respective arguments */
return myModule;
});
} else {
if (root.hasOwnProperty(/* dependencies */)) {
/* var dependencies = root... */
root.myModule = myModule;
}
}
})(this);
This keeps dependants with a common name, across environments. However, the question remains: Why is the global object not available within the closure's scope?
EDIT 2 I've been experimenting with RequireJS and AMD and have corrected my code, above, so that the AMDs work. Exactly the same thing happens in this case, too: You have to explicitly assign the global object to a variable within the closure for it to be available within said closure...

This pattern works just fine. If you actually tested it with a function called super and calling it via super(), you might ran into an error, because super is a reserved word. Following code works fine:
(function(root) {
root.super = function() {
console.log("hello");
};
}) (window);
(function(root) {
root.super();
}) (window);
You can call your function using window.super(). super() however will result in an error.