Support commonjs environments

[Adam Peller]

I'm experimenting with using Dojo in ​Jack-JS, a Rhino-based app server that lets you write your server apps in JavaScript. It supports a community driven effort to standardize JS APIs for servers called ​CommonJS (formerly called serverjs)

CommonJS has a module loader that is somewhat like Dojo's own. The two don't seem to map to each other, but I think they can peacefully co-exist. A few tweaks are needed to the bootstrap to support the 'exports' free variable used to anchor references, such as the Dojo object itself. Once we're bootstrapped, we can have a special serverjs hostenv. For the purposes of getting things running on Jack, I just based it on Rhino, but hopefully we can build it on ​SecurableModules such that the hostenv will run in any SSJS environment.

see also #7757

[James Burke]

It seems like the tasks might be the following:

• Have a serverjs_hostenv.js. This file should use plumbing similar to whatever is under serverjs's require() as far as reading files and evaling the content. Hopefully they have a wrapper for those functions and it is not serverjs-host environment specific. That would balloon the number of our _hostenv files. Maybe instead of the rhino-equivalent of "load" we can use the serverjs require() call itself to load and eval the code.

• Make sure we can access the global object so we can attach our top-level namespaces, and set dojo.global appropriately. This will allow us to properly load top-level namespaces like dojox/dijit.

• Do we need to override the serverjs require? So, if we notice the require call is for a dojo-known namespace we do our dojo.require stuff, then we can just export that module. So if require("dojox.foo") we do a dojo.require("dojox.foo") then we do an exports = dojox.foo (or if we cannot overwrite the exports object, do a dojo.mixin).

That might be enough to get dojo to operate in that environment. The next thing might be able to allow people to dojo.require() serverjs modules. Maybe that is a separate ticket. I think we can get it to work by adding a "var require = dojo.require;" before the text for the module, and then set up exports to an object that is based on the dojo.require() for that module (*not* the dojo.provide call, since the module won't have one).

[Adam Peller]

@James: you'll see my feeble attempt at a hostenv_serverjs file in the patch. I only replaced the load() call, but in my local repo I've replaced the code that does the file I/O also. Do you remember what all that stack walking was about? I don't see the scriptLibraryUri config actually used anywhere?! I do hope serverjs provides the full path of the required dojo.js file soon... I've asked for this.

This would add one hostenv which would ultimately be able to cover a wide array of server-based hostenvs, so I think it's a big win. Could get us running soon-ish on v8cgi, etc.

I'm not sure setting exports does us any good unless we consistently apply exports=* in our code. Also, it would be about supporting a new paradigm where SecurableModules? require could be used directly on a dojo module? I'm not sure I've figured out if there's a match here or not but I think what we have now lets the two systems live side-by-side, more or less.

[James Burke]

peller: I saw your patch with the new hostenv. It still contained a fair amount of Java stuff though. I am hoping all the Java references go away. I saw the starting of the serverjs changes, but I figured I would try to identify what we need to change so we have a target, but I am not totally familiar with the environment yet.

As far as the path to dojo.js, I wonder, do they set some sort of environment variable for where all the scripts get loaded from? If so, maybe we can use that?

About libraryScriptUri, I have a ticket for removing it (#6912), I just have not had it on a priority list to get to it. I have not been able to find where it is used, so that should get rid of some debris in that file. libraryScriptUri was like baseUrl in the olds days as I recall, but now only baseUrl is used.

We might be able to skip the export work for now, or at least open a different ticket if/when we get there. As you say, probably as long as we can load dojo, and you can use your dojo code in a serverjs environment, that is a good first step.

[Adam Peller]

updated hostenv_serverjs.js uses more ServerJS APIs -- only setTimeout remains

[Mike Wilson]

Interesting.
(this is really a nonsense post to activate cc - how is this done without adding a comment?)

[Karl Tiedt]

Mikewse, just edit the CC list and "submit changes" ;)

[Dustin Machi]

I created a little commonjs wrapper package here, ​http://github.com/dmachi/dojo that works with narwhal at least, and possibly some of the other envs. I'll update this to match the work from #7757 that was agreed on.

[bill]

(sadly) punting seemingly abandoned ticket and meta tickets to future

[bill]

Seems like #12357 will fix this?

[Dustin Machi]

This ticket represented work that went on prior to the full amd push and has since been superceded by that set of work.