volojs / volo Goto Github PK

@dmose noticed some issues with the ghdeploy command, if the password is incorrect, the next time, the prompt is difficult to break out of -- CTRL+C and CTRL+Z do not work.

The wrapper amdify uses doesn't seem to guard against using a library without amdify, e.g., testing if typeof define == "undefined"

Right it dies pretty badly when network is not available. Need to give a user friendly message indicating the problem.

Does it make sense to have a "serve" command that can start up a static web server for the directory?

Probably means shipping something like node-static or some other lib. Are licenses compatible? There is a pretty easy python one-liner floating around, maybe just suggest using that instead.

Steps to reproduce

1. git clone git://gist.github.com/2952133.git path.with.dots (link)
2. volo create testapp && cd testapp
3. volo add ../path.with.dots/

Output

Downloading: http://code.jquery.com/jquery-1.7.2.js

Installed github:jquery/jquery/1.7.2 at www/js/lib/jquery.js
AMD dependency name: jquery
Installed local:/Users/brant/Code/path.with.spaces at www/js/lib/foo.bar.js
AMD dependency name: path.with

Volo uses the "path.with" as the AMD dependency name instead of "path.with.dots".

This can be worked around by specifying the dependency name explicitly (volo add ../path.with.dots/ path.with.dots), but the default behavior seems incorrect.

Right now volo uses 'master' if no version tags, but some repos use another convention like 'develop'.

Doing a get on the repo via github api:
http://developer.github.com/v3/repos/#get

the data has a "master_branch" property. Use that value instead of defaulting to "master" always.

How would one specify a dependency on the text! plugin? If I have a package.json file, how can I indicate that I would need a text.js file in the scripts folder to be downloaded and generated?

Would one have requirejs itself as the dependency, and then reference the plugin as requirejs/text? If this was the case, then surely the standard inclusion of requirejs in the web application templates would need to be done this way anyway to avoid duplication. Since requirejs itself requires some amd steps, this feels like a bit like a hack.

The text dependency can be very useful in a lot of cases, for example when writing templating plugins it can be useful to simply reference methods from the text plugin itself in order to avoid rewriting the xhr code (as many template plugins seem to do). Similarly for the optimization stage.

Since 'acquire' uses 'add' but changes the cwd, then any relative symlink: path will be relative to the volo directory, not the directory used to start the volo command. Fix it.

If an add has AMD dependencies, then scan for them and then install them. Likely it needs a resolution to Issue #7 and perhaps being able to read a package.json mappings property or volo.mappings property.

Using volo in a project subdirectory should find the volofile along the parent directory path instead of failing.

When trying to create a project or add a library, the installation fails for me with this error:

$ volo add jquery
Using github repo "jquery/jquery" for "jquery"...
Downloading: http://code.jquery.com/jquery-1.7.2.js
Error: EXDEV, cross-device link not permitted '/tmp/temp-jquery-1334146881598-1/download/jquery.js'

Executing 'volo rejuvenate' when one is not in the parent dir of volo fails with the following error:

Error: ENOENT, no such file or directory 'volo'

Right now, "volo add EaselJS" pulls the master branch, even though tags are available, because the tags have a somewhat unusual format; https://github.com/CreateJS/EaselJS/tags has examples. It strikes me as reasonable to include "prepended with release_v" into the heuristic that's currently used.

volo add crafty
Using github repo "craftyjs/Crafty" for "crafty"...
Downloading: http://craftyjs.com/release/0.4.8/crafty.js
Installed github:craftyjs/Crafty/0.4.8 at www/js/lib/Crafty.js

The fact that the thing called crafty.js on the server gets renamed to Crafty.js seems wrong to me. Presumably most non-volo users are likely to use (and be used to using) the file as it is named on the server.

I was wondering if an update command was in the mix. It would be sweet if you could just do a "volo update" and get all the latest version of the dependencies listed in the package.json file.

Make sure no deprecated APIs are used. path.existsSync is not fs.existsSync for instance.

Get pretty colors in the help command output and console messages. How best to do this?

Discussing with @dmose: it would be nice to have a volo.baseUrl for projects that are not AMD-based or not purely AMD.

So it's only possible to create a project in the current directly. This seems unusual for a command-line thing.

Is there some reason not to accept to the syntax

volo create /tmp/myApp templateName

?

Allow a local: archive url in volo/resolve to allow copying over files from a local directory vs the already supported symlink:

So attempting to execute a rejuvenated volo returns "permision denied".

If you call build.sh from another directory, r.js can't be found.

One solution for bash is to use $BASH_SOURCE, like HERE="$(dirname $BASH_SOURCE)"

At least testing that r.js exists would allow for a better error message.

Hello,

I just installed node.js, volo.js and trying to create a project. Somehow i constantly getting an error which looks like this:

PS D:\Alexey\Work\Volo> node c:/Users/user/scripts/volo.js create myproject volojs/create-responsive-template
Downloading: https://nodeload.github.com/volojs/create-responsive-template/zipball/master
Error: ENOENT, no such file or directory
PS D:\Alexey\Work\Volo>

with default project template i get the same:

PS D:\Alexey\Work\Volo> node c:/Users/user/scripts/volo.js create myproject
Downloading: https://nodeload.github.com/volojs/create-template/zipball/master
Error: ENOENT, no such file or directory
PS D:\Alexey\Work\Volo>

Can you please help with with this issue?
Thanks in advance,
Alexey

Reported here:

https://groups.google.com/forum/?fromgroups#!topic/volojs/emZqvSlNq3w

Any installed package with a package.json that will install a directory is not using the depPackageInfo info, but instead the "info" variable, which is not set up when the package.json was already fetched from the net. around line 384 in add.js.

Serious regression, push out 2.0.1 soon, triaging other bugs out to 2.0.2 if need be. A regression that even affects packages like dojo.

It seems like the executable flag is removed after rejuvenate runs. Look at reading the executable flags before update, then restore them after the update.

If I skim the volo "binary", it looks like it might have the RequireJS optimizer goodness inside. I expect that will happen someday, but hasn't happened yet. A brief word in the readme that I should use RequireJS for optimization for now would reassure me that I'm not doing things wrong.

Right now, unless I'm mistaken, one needs to land a package.json file in volojs/repos before one can actually test whether or not it works.

Perhaps an "--with-package-json=path/to/overide/package.json" switch?

If 'underscore' or 'jquery' is installed locally as 'foo', then the named AMD call in the file should change to update. Note that only the define() call that matches the old name should be changed -- if more than one define call in the file, then need to modify to a named module instead of just removing it to make it an anonymous module.

I created an override package.json with a bug in that it pointed to an https URL where there was no server running, rather than
the correct http URL. The error message given makes it looks like the problem happened while contacting github:

volo add crafty
Using github repo "craftyjs/Crafty" for "crafty"...
Error: connect ECONNREFUSED

By the time you read this, I expect to have fixed the override volofile, but it should be easy to reproduce. :-)

Ideally a dependency could just be specified as 'backbone' and by hitting the github API it could be determines that it should be 'documentcloud/backbone' for the github archive.

Unfortunately the v3 of the GitHub API does not have a search API, unlike v2. Need to figure out the story there, but that would be the ideal API to use.

Perhaps using the google search API could be used, but it has a pretty low free search result cap. At that point it may make sense to run a server that caches short name lookups to the longer names, but ideally a server would not be needed.

For spelled out words, it is common in unix programs to specify them via --word.

I would expect, e.g., volo create -h to show something about the create command, but it does not.

If a command is available in the sibling volo directory, favor it over using a version that is built into volo.js.

Probably means needing a module undefine support/unregister from volo/commands.

Awesome to see that #8 is closed and volo is starting to resolve dependencies. Just trying it out on one of my projects and have noticed that the localName argument is not respected for dependencies.

If I run the following command, where green has a dependency on blue

volo add green somewhere

The somewhere directory is created and green is added to it. Then add is called again with blue as the argument, only this time localName is not respected and so blue is added to the current directory not somewhere

Cheers

This file:
https://github.com/andris9/mailparser/blob/master/lib/datetime.js

whose content is basically:

this.strtotime = function(str, now) {
}

Does not amdify properly. When I use npmrel, the wrapper is:

//Wrapped in an outer function to preserve global this
(function (root) { define([undefined], function (undefined) { (function () {
....
}.call(root));

undefined
}); }(this));

When I manually use amdify, it looks similar, but the undefineds aren't there. FWIW, the module does work "properly" in node.

In the process of figuring out how to do the following:

• allow dependencies for commands in a volofile
• allow use of project-local npm-installed modules
• allow installing reusable components for volo in the current project (project-local)

It seems like it will be better to go with the grain of node instead of some of the custom packaging that volo uses for itself and the use AMD modules for volofiles.

The main goals of volo for me are:

• Promote the use of github for project templates and installing front end dependencies. Front end devs are likely already using github in some fashion, and github, with its tags, branches, downloads area, and built in social features for reporting back issues/interacting with library developers is a better fit than using npm for these tasks, particularly given the nodeisms built into npm.
• Allow other node-based software to reuse the github awareness that volo has for doing searches, resolving github identifiers (owner/repo -> owner/repo/latestVersionTag), and generating URLs to version archives.
• Allow using node to create simple makefile-type of scripts for running project tasks: volofiles. This means the onCreate and onAdd hooks too.

These goals are still achievable with structuring volo as plain npm-installable package. I like being able to have a simple, single file JS file for volo that a user just puts in their path (or have multiple copies). However, node is required to run, and the user will likely want to install other npm-installed packages, like jshint, for use in their project's volofiles.

Making that process similar to how node normally operates probably outweigh my personal aversion to globally installed packages in node, the single namespace/package.json name limitations in npm, and my desire to encourage single file JS file installations for node-run utilities.

What does this mean practically?

For normal use it just means using npm to install and update volo. No more volo rejuvenate and volo acquire. Once installed via npm, volo [command] will work as before.

The change to volofiles is the biggest change. volofiles will need to do module.exports = {} instead of define(function (require) { return {} }); to take advantage of future volofile features.

The 0.2 volo will still understand the old volofile syntax though, so you do not need to change your volofiles right away. However, to get the newer inter-command dependency support and local npm-installed package support for volofiles, the new syntax will be needed.

Extreme example of the conversion:

Old format:

define(function (require) {
    //This volofile uses the 'amdify' 'q' and 'volo'github' module
    //from the modules included in volo.
    var amdify = require('amdify'),
        q = require('q'),
        github = require('volo/github');

    return {
        //Define a foo command that can be run via "volo foo"
        foo:  function (d, v, namedArgs, appName) {
            amdify();
            github();
        }
    }
});

new format:

//Any module installed in this project's node_modules
//directory can be used.
var jshint = require('jshint');

module.exports = {
    //Define a foo command that can be run via "volo foo"
    foo:  function (d, v, namedArgs, appName) {
        //Use v.require to get modules from the volo package.
        //commands are in './commands' and helper modules are
        //in './lib'. volo also ships a version of 'q'
        var amdify = v.require('./commands/amdify'),
            github = v.require('./lib/github'),
            //Could use require('q') if this project has a
            //node_modules with 'q' installed
            q = v.require('q');

        amdify();
        github();
        jshint();
    }
};

Comments are welcome. I have a proof of concept working in the prime branch, with all the tests passing.

I've spent the past few days writing volo commands and it seems as though any and all errors are being swallowed by volo. Is there a way to have volo throw errors to the console rather than just silently failing?

So that they do not fail with older volo versions.

I'm trying to run this from a custom volo command:

    v.command("add", template, name)
     .then(function() {
         console.log("this is never reached")
      })

However, the resolve handler is never called. I've tried logging throughout the code in v.js and main.js and see no reason for the then handler not to run (the add command executes fine.) A fail handler is called correctly however.

It did make me think about the semantics of the command though. If I understand the code correctly, the resolve handler should be called once the command has been executed but not necessarily finished? There's a good chance I'm misunderstanding this, and I think it needs clarifying. If I am getting it right, should this be changed so that the resolve handler is only called once the command has finished executing?

Spin up a local webapp via node, do the oauth jumps, save the token in the volo config file.

Likely implement as a new command for the acquisition of the token, but have "volo/resolve/github" be aware of how to use the token if in the volo config file.

Right now libs that want to upgrade to volo in their package.json it will not take affect until the first tagged release. It would be good if they could just commit to their master branch, and have volo check that version before going to the shim repo.

Ideally #37 is fixed too so that the correct master branch is chosen for the project. But chosing "master" for now would work.

For common projects, so that it is easy to auto-upgrade them to AMD or stamp config with the information without having to ask the end user to specify this information.

Maybe a "volojs/dependencies" repo and the directories are of the form:

owner/repo/deps.json

where deps.json are of the form:

{
    "deps": ["jquery", "underscore"],
    "exports": "Backbone"
}

It's sometimes very hard to figure out what's wrong with a volofile, and the ability to hook up a debugger like node-inspector would be immensely useful. However, adding --debug or --debug-brk when running volo seems to do nothing.

Is there a way to do this currently, that I'm unaware of?

I'm not sure if this feature is already planned (or implemented and I just didn't find it), but I would really like install all volo dependencies listed in the package.json file with one command as "npm install" installs all node dependencies listed in the current directory's package.json. With that I would get one large step closer to not having jquery, backbone and friends in my repository.

Work it out. Some things in particular:

• Right now tar -z and rm are used via child_process. How does that work in Windows? Show zip files be used instead? Is there a reliable zip utility that can be used in Node, something that is not a binary component that needs to be built to ship volo?
• How would symlinks work?

I've given PreloadJS the following package.json in repos/

{
"volo": {
"url": "https://raw.github.com/CreateJS/PreloadJS/{version}/lib/preloadjs-{version}.min.js"
}
}

This turns out not to work, and I suspect at least part of it is a github side optimization. It turns out that if you go to
https://github.com/CreateJS/PreloadJS/blob/release_v0.1.0/lib/preloadjs-0.1.0.min.js, which is the 0.1.0 release tag and click on the "raw" link, you'll end up at https://raw.github.com/CreateJS/PreloadJS/master/lib/preloadjs-0.1.0.min.js. Note that we're now pointing to the master branch, perhaps because this file hasn't changed on the master branch since 0.1.0 was released. It kinda looks like we're going to need two interpolation variables to fix this....

See notes here:
http://docs.python.org/library/tempfile.html#tempfile.tempdir

The current set used by volo matches npm's behavior, but compare to see if the Python one is more robust.

As an example:

$ volo add -amd alankligman/gladius/develop
Downloading: https://nodeload.github.com/alankligman/gladius/zipball/develop
TypeError: Cannot read property 'main' of undefined

$ volo add -amd alankligman/gladius/develop
www/js/gladius already exists. To install anyway, pass -f to the command

Update anything that mentions it being a single JS file.