Opened 5 years ago

Closed 3 years ago

#9349 closed enhancement (wontfix)

Support commonjs environments

Reported by: peller Owned by: dmachi
Priority: high Milestone: 1.7
Component: Core Version: 1.3.0
Keywords: Cc: jburke, alex, elazutkin, liucougar
Blocked by: Blocking:

Description (last modified by 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

Attachments (2)

serverjs.patch (11.8 KB) - added by peller 5 years ago.
hostenv_serverjs.js (3.1 KB) - added by peller 5 years ago.
updated hostenv_serverjs.js uses more ServerJS APIs -- only setTimeout remains

Download all attachments as: .zip

Change History (16)

Changed 5 years ago by peller

comment:1 Changed 5 years ago by jburke

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).

comment:2 Changed 5 years ago by 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.

comment:3 Changed 5 years ago by peller

  • Component changed from General to Core
  • Type changed from defect to enhancement

comment:4 Changed 5 years ago by jburke

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.

Changed 5 years ago by peller

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

comment:5 Changed 5 years ago by elazutkin

  • Cc elazutkin added

comment:6 Changed 5 years ago by mikewse

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

comment:7 Changed 5 years ago by peller

  • Description modified (diff)
  • Summary changed from Support server-js environments to Support commonjs environments

comment:8 Changed 5 years ago by ktiedt

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

comment:9 Changed 5 years ago by peller

  • Milestone changed from tbd to future

comment:10 Changed 4 years ago by dmachi

  • Milestone changed from future to 1.5
  • Owner changed from peller to dmachi

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.

comment:11 Changed 4 years ago by peller

  • Milestone changed from 1.5 to 1.6

comment:12 Changed 3 years ago by bill

  • Milestone changed from 1.6 to future

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

comment:13 Changed 3 years ago by bill

  • Cc liucougar added
  • Milestone changed from future to 1.7

Seems like #12357 will fix this?

comment:14 Changed 3 years ago by dmachi

  • Resolution set to wontfix
  • Status changed from new to closed

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

Note: See TracTickets for help on using tickets.