The Command Line

That’s great seeing all that code but not being able to use it is another thing. What have we done so far?

If you open a command line to where the package.json file is and use the command

$ npm install

Grunt will install all of the plugins listed in the devDependencies into a node_modules folder. After that you we can get a list of the available tasks by running:

$ grunt -h

Once that is run, you will see something like the following:

Grunt: The JavaScript Task Runner (v0.4.5)

Usage
 grunt [options] [task [task ...]]

Options
    --help, -h  Display this help text.
        --base  Specify an alternate base path. By default, all file paths are
                relative to the Gruntfile. (grunt.file.setBase) *
    --no-color  Disable colored output.
   --gruntfile  Specify an alternate Gruntfile. By default, grunt looks in the
                current or parent directories for the nearest Gruntfile.js or
                Gruntfile.coffee file.
   --debug, -d  Enable debugging mode for tasks that support it.
       --stack  Print a stack trace when exiting with a warning or fatal error.
   --force, -f  A way to force your way past warnings. Want a suggestion? Don't
                use this option, fix your code.
       --tasks  Additional directory paths to scan for task and "extra" files.
                (grunt.loadTasks) *
         --npm  Npm-installed grunt plugins to scan for task and "extra" files.
                (grunt.loadNpmTasks) *
    --no-write  Disable writing files (dry run).
 --verbose, -v  Verbose mode. A lot more information output.
 --version, -V  Print the grunt version. Combine with --verbose for more info.
  --completion  Output plain auto-completion rules. See the grunt-cli
                documentation for more information.

Options marked with * have methods exposed via the grunt API and should instead
be specified inside the Gruntfile wherever possible.

Available tasks
        default Alias for "watch" task.
            zip Alias for "compress" task.

Tasks run in the order specified. Arguments may be passed to tasks that accept
them by using colons, like "lint:files". Tasks marked with * are "multi tasks"
and will iterate over all sub-targets if no argument is specified.

The list of available tasks may change based on tasks directories or grunt
plugins specified in the Gruntfile or via command-line options.

For more information, see https://gruntjs.com/

What’s cool is that if you look closely you will see in the Available tasks that a task is named zip. This is what was created in our Gruntfile.js file and now we can use that in our command line to create a zip file of our project by simply running

$ grunt zip

Grunt will do its thing and create the file for you. It may take a few moments depending on how big your project is.

What next?

I did mention Bower, SASS, and version control but only as optional things you can use.

Bower is a little like Grunt in that you can declare devDependencies and install them in the same manner you would with Grunt.

$ bower install

This will install all bower packages you list in devDependencies. You can then configure your Gruntfile accordingly to better suit the project you are working on by making sure that your source folders and files correspond properly. It works amazing when you are using SASS to compile your CSS files.

CSS is a great thing but using a pre-processor is even better. Yes, SASS is a great development tool and using bower to include susy is one way of creating your own custom layouts and grids. That is if you don’t want to use a pre-built CSS framework or even learn one. With Grunt you can compile the CSS before compressing or distributing your project.

So, go on and tinker with Grunt. Create a random project if you haven’t and break the command line. I mean how else are you going to learn how things break?