Make shotgun browserify compatible?

[PeterHancock]

If it was not for the loading of the default commands shotgun would work in the browser (e.g with something like JQuery Terminal) using browserify.

Assuming the default commands will not be modified too often, is it possible to adapt the code so that they are 'required' and manually registered in index.js?

I can see that 'exit' and 'clear' just fire the corresponding events - there could be a shotgun API method for commands that just trigger events. e.g.

registerEventCmd: function(cmd, event) {
    event = event || cmd;
    this.registerCmd(cmd, {
        invoke: function(shell) {
            shell.emit(event);
        }
    })
}

BTW, I am assuming that shotgun-client does not provide a way of using shotgun in the browser?

[PeterHancock]

The loading of custom command modules also causes issues too.

[chevcast]

Shotgun client currently requires shotgun to be running on the server, though I think it could be adapted to also allow shotgun to run purely on the client. It would be a little involved but I think it's doable. We already added an API method for registering commands programmatically so it does make sense to load default commands as individual requires using the API instead of passing the default_cmds directory to the load function.

I will modify shotgun to load default commands using explicit require calls instead of the directory loading function. Do you know what browserify does with the fs module? Obviously that functionality won't work in the browser so I'm curious if I would have to totally remove it in order for it to be browserify compatible.

[chevcast]

I really don't want to lose the convenience of auto-loading command modules from a default directory. My first idea was to just make shotgun detect if it's in the browser and if so, skip auto-loading. However, this means the user will now have to modify their app so that they manually require their own command modules and manually register them with the shell. If you have hundreds of modules this would be a huge pain.

Since we already have a "shotgun" shell script in the bin directory that generates code scaffolds I was thinking that it would be trivial to add a "shotgun-browserify" shell script in addition to modifying shotgun to detect if it is running in the browser. In addition to passing in your app's main entry file to shotgun-browserify you would also pass in one or more command module directories. shotgun-browserify would loop through all your modules and generate a file that manually requires them and adds them to the window.shotgun namespace under the same name as the directory.

For example, Running shotgun-browserify against your shotgun app with the default settings all your modules would end up in an array attached to window.shotgun.shotgun_cmds in the resulting bundle. Then shotgun will be modified so it knows if it is in the browser. If it is in the browser then the module loading functions will look for modules there instead of in the file system.

I will also make it so that default command modules are explicitly required in shotgun so that browserify can bundle them properly. You are right that the default commands almost never change and I've yet to once add new ones or remove existing ones, so dynamically loading them isn't providing much benefit here.

[chevcast]

I think you'll be happy about this one. So far this just exposes the shell (no interface helpers) but I already have a jquery console plugin I wrote for shotgun-client. I intend to adapt that to work with client-side shotgun in addition to shotgun-client.

I'm likely going to rename shotgun-client so that it better represents what it is. I'm also configuring rewriting shotgun-client now so that the client-side API is actually a client-side shotgun app :D

[PeterHancock]

This is really great Alex! The out-of-the-box setup here looks very simple and with no explit dependency on browserify!

Hats off to your speedy implementation!

[chevcast]

I'm glad you like it :)