|Page 1 of 1||[ 7 posts ]|
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.
Yours was the first set of NodeJS modules to be added to the Gallery, so it's new to us too.
After discussing it with the team, we came to the conclusion that CDN access is a browser only solution. It should not be the recommended way to include a YUI module on the server.
Now, with that said, we don't know just yet the best way to package YUI gallery modules via npm and make them includable by default.
We do know that we "eventually" want to automate the npm packaging for all modules per build, but we haven't settled on that yet as I have been working more on making YUI run better on Node natively.
My first thoughts are to make a gallery module packageable via npm with a custom index.js file that will export a Y instance with that module already attached. Then also dynamically create a module config for it so you could do something like this:
var Y = require('my-gallery-module').use(); //Or something
Y.MyGalleryModule is available
}).use('event', 'oop', 'base', 'my-gallery-module');
Just thinking outloud here since this is new territory for all of us
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.
Check out my video on what I have been working on when it comes to packages:
The packaging info is available here, along with the scripts:
https://github.com/yui/yui3/blob/master ... .nodejs.md
I don't know if it is relevant to your case, but you may give a look at two examples using npm: photosnear.me  and conpa .
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,
Thank you for these resources. I'm probably not going to go through the process of publishing through NPM at this time. I just wanted to make this available to the community. A manual install process is available enough for this for now.
I have another question though, probably something else that has yet to be figured out...
For now I'm assuming that the gallery's build process builds all of the modules in the yui3-gallery repo and adds them to the CDN, so you don't want to pull my modules into yui's fork. Is the best thing for me to do now to git rm the files from my fork and make them their own individual repos? or should I leave them where they are until some time in the future when the gallery build process will know the difference between CDN modules and Node.js modules?
I would leave them in your fork so we have modules to work with when we finalize the NPM packaging process for the gallery.
|Page 1 of 1||[ 7 posts ]|
|You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum