Forums

Hello, I recently added a couple of modules to the gallery which are designed for Node.js. When I submitted a CDN request, I received a message that my CDN request was denied. "NodeJS modules have no reason to be on the CDN, the CDN is for browser based modules only."

The YUI team has every right to select what does or does not go on their CDN, but this is disappointing to me; I have been enjoying the use of other gallery modules from within Node.js. Without the CDN, and without being able to do require('yui3').YUI().use('gallery-module'); everything just became more difficult. I have lots of questions.

What is the recommended way of distributing and installing the module so I can add install process instructions to my module descriptions? If there are other Node.js gallery modules, for user convenience, it would be better if everyone is using the same install procedure instead of making up something.

What's the best way to serve the installation files? A tar.bz2 of the build folder? Clone the repo, use ant, and copy? Could NPM somehow be utilized for any of this process?

How can I manage dependency resolution? I was counting on loader to figure this out. One of my Node.js gallery modules depends on the other, so when installing one, the other should get installed too. Then loader has to be given a specific config object with modules and file paths. Since my module names have a 'gallery-' prefix is that going to mess up with the logic for loading other gallery modules?

Is there a conventional installation folder for custom YUI modules in Node.js? If so, it would be great if loader knew about it so custom modules placed there could be loaded with use() without a big config object.

Thank you very much for your reply. This makes sense, it was just unexpected. I'm not in a hurry to have these things worked out but I'm glad to know they are being thoroughly thought out. I haven't published anything with NPM but that seems like the best way to go, especially if it can manage dependencies.

My first thoughts on your examples:

var Y = require('my-gallery-module').use();
That is a nice short cut. This makes the module feel like it stands on its own instead of hiding in a YUI sandbox. The user of this module doesn't even need to know YUI is there. There are good use cases for this. If there were multiple modules using this pattern, could they somehow share the same Y instance if they wanted to?

The idea of a required module that just returns a module definition object for loader is really nice. I'd rather not need the loader configuration object. If there is a known install location and a common module name prefix, could modules load normally (without a require()) like gallery- and yui2-?

For now I'll update my module descriptions to note that users have to clone my repo, copy the build folders out, and add loader configs to point at where ever this files are. It's probably good that it's very difficult to use the SQL*Plus module. It's just a hack to fill in some missing functionality and by myself I can't put forth enough testing effort to feel good about it. (I've already found some nasty edge cases which cause deadlocks in Oracle!)

I have a couple more ideas for Node.js specific gallery modules but they are very low on my priority list at the moment. Thank you very much for all the work you are doing to make this an excellent framework.

Steven,
I don't know if it is relevant to your case, but you may give a look at two examples using npm: photosnear.me [1] and conpa [2].

The first one has express module as dependency. The second one expects an express instance, having as dependency also the backend, a real - server-side - node.js module.

Hope that helps,
Alberto

[1] http://github.com/ericf/photosnear.me
[2] http://github.com/albertosantini/node-conpa

I would leave them in your fork so we have modules to work with when we finalize the NPM packaging process for the gallery.