There's a lot of command tools out there written by developers to help them automate all sorts of tasks from code refactoring, linting, and builds. Node has become a popular tool to write reusable tools that can be run from the command line, but many CF developers don't realize that CommandBox has allowed developers to do this nativley in CFML for years now.
CLI Goodness
Writing a CLI tool sounds a little scary, but it's actually very easy-- as easy as a CFC containing a single method. Let's take a look at a real CLI command that you can run on CommandBox:
/commands/hello.cfc
component { function run(){ return 'Hello World!'; } }
Hey, that's not so bad is it? By convention, the name of your command will be the same as the CFC name (hello
) which means you'd run the above like so from any operating system:
$> box hello Hello World!
Now you can add this command to Jenkins builds, package scripts, cron jobs, cfexecute, or just from your local bash shell!
Interactivity
But there's more you can do. A lot more. I'm a little biased, but I honestly think CommandBox is better than Node in several of these areas. Check out this cool stuff you can add into your new command line tools:
- Nest commands into names spaces like
coldbox create app
,coldbox create module
, etc - Accept named or positional parameters with no manual parsing or additonal libs needed.
- Users are automatically prompted for missing required params
- Easy boolean flags out-of-the-box like
--force
- Super-easy ANSI formatting like font colors and decoration like
print.blueText( 'sad panda' )
- Bullt-in tab completion for your command names and parameter name/values
- Automatic help screens generated right from your CFC's metadata
- Complete interactivity with your users via helper methods like
ask()
,confirm()
, andwaitForKey()
- Automatically send back proper exit codes to the OS when an error happens
- Nice helpers for finding current working directory, expanding relative paths, and getting terminal size
- Even access a database via on-the-fly JDBC connections.
Where do I start?
Want to play around with all this? 100% of what I mentioned above is documented right here in our docs: https://ortus.gitbooks.io/commandbox-documentation/content/developing/commands/developing_commands.html
That page will walk you through creating your first command in only a few minutes. And when you're ready to share your work with the world, just stick it in a GitHub repo and use the publish
command to send it up to ForgeBox. Setting up some package scripts will even help manage all your versions. When I want to make changes to a command live, I just have to type this and my package scripts take care of tagging the repo, pushing to GitHub, and publishing the latest version to ForgeBox!
CommandBox> bump --minor
Examples
Some people like to learn from checking out existing projects. Feast your eyes on these example CommandBox modules that have custom commands in them:
- Chuck Norris quotes
- Image to ASCII (art) generator
- FW/1 scaffolding commands
- CommandBox banner customizer
- HTTP Command (like curl)
- CFWHeels scaffolding commands
- CommandBox Ngrok
- CFConfig CLI
Any of those projects above can be installed globally into your local CommandBox installation just like this:
CommandBox> install commandbox-chuck-norris
Get going
OK, you have the tools. You're a CF dev and it's time you put some of your totally aweseome ideas into action. Go and create some sweet stuff, then show your friends and watch their suprise when you tell them your new CLI tooling is written in ColdFusion!
Add Your Comment
(5)
Mar 02, 2017 17:46:09 UTC
by Adam Cameron
Interesting stuff. Given you mention it, it'd be good if you could actually objectively (or, hey, even subjectively!) quantify how "CommandBox is better than Node in sevearl of these areas".
Mar 02, 2017 18:25:51 UTC
by Luis Majano
Thanks for your comment Adam! I am sure that would be a cool blog entry to do separately so as to distinguish our differences or do a compare-contrast objectively. Inherently, there are architectural and language differences, so we cannot compare apples to apples in many areas. However, there are many areas we can do this and we have improved upon NPM and Node CLI as well. We had the pleasure of analysing how these tools work and be able to take the best out of them and port what we thought would be best over to CommandBox. Off the bat our caching strategy for artifacts is part of CommandBox which does not exist in NPM, which makes CommandBox package resolving and installation way faster and better performant. I'll let Brad comment (While I go get some popcorn)
Mar 02, 2017 20:03:37 UTC
by Adam Cameron
G'day Luis. I reckon of the article was just "commandbox is good, and you can do this", then it's fair cop to not justify one's self. But an article which makes a point of saying x is better than y, then it's *slightly* disingenuous to just say it rather than actually explaining / showing how x is actually better than y. This kinda reads more like an advert than exposition. But I guess advertising *box stuff *is* Brad's raison d'etre ;-) That said: it's a good teaser for commandbox commands. And I look fwd to reading a more meaningful comparison. Cheers!
Mar 02, 2017 20:05:00 UTC
by Adam Cameron
PS: your comments system are swallowing paragraph breaks. My previous comment wasn't one run-on thought, it was three paras. Maybe you need a FormatBox or something ;-)
Mar 03, 2017 01:55:30 UTC
by Brad Wood
Hi Adam, that's a fair question to ask. I've expounded on the way I think CommandBox is better than npm at creating CLI tools, but I did so on my personal blog as to not clutter the comments here. http://www.codersrevolution.com/blog/why-writing-cli-scripts-in-commandbox-is-better-than-node