To refactor or not to refactor?

Now we have two commands, to play with.

  1. firstCommand.js
  2. secondCommand.js

The SecondCommand class depends upon the output of the FirstCommand class. This sounds like we need a different strategy then before, to run the SecondCommand. Since you cannot run the second command without running the firstCommand first, it seems we need to refactor our application ‘myFirstApp.js’.  Maybe run two kickstarters after each other. One for each command?

Macro to the rescue

Luckily for us, no refactoring is needed at all. This is the situation where the macro-command perfectly fits our needs. The only thing that is going to differ from the single-command-mode situation, is the configuration file. In single-mode we used a config-file that had the same name as the command-file (except for the file extension). In macro-mode, we must use the config-file as specified in the macro-command’s own config-file:

So in our case this was:

Now let’s edit our own (macro) config.json to specify a new macro and configure it. The result should look like this:

First you create an object with key ‘macros’. Then you have the following five keys:

  1. id* – the id of the macro which must be unique.
  2. label – a name for your macro
  3. comment – a short description for your macro
  4. namespace* – a subdirectory of the commands dir, in which your commands can be found. It can be many levels deep. When your commands are in the root, or have different namespaces, set this value to ‘false’ or leave out the parameter completely. When using multiple namespaces in one macro, you must specify them in the cmdSequence parameter. Just place them before your command names like a relative path: ‘my/namespace/myCommand’ or ‘my/other/namespace/commandX’
  5. cmdSequence* – the list of command files that you want to run. They will be executed in the order of the list. (left to right)

The keys with an asterisk (*) are required!

  • firstCommand – any required configuration for your command
  • secondCommand – any required configuration for your command

Those are optional, but give a warning at the console when missing.

How about the application?

This is super simple. Whenever a kickstarter get passed a value of type ‘string’, it will run in single-mode. Otherwise, when it gets passed a value of type ‘number’ it will run in macro-mode. The number must be a valid macro-id. So lets change our application ‘myFirstApp.js’ by just passing in a macro-id instead of a command-name,

and then run it:

The output should now look like this:

How cool is that!


Although it took me a lot of words to describe the whole process of defining a macro, it only took a few lines of code. Specially when you build larger macro’s then this, the macro-command package will save you a lot of time. You can re-use your valuable code and build upon it, to make it even more powerful.
I hope this tutorial gets you up and running real quick. As a little bonus, I will create a download link for the example project, so you can look at the code without having me distracting you.
One thing we did not discuss yet, is the strategy for documenting your commands. I will do this in the very last part of this tutorial. So hang on, were almost there…

(Download the project as zip-file)

< Previous part    |    Next part >