On Github mgburns / grunt-presentation
Created by Mike Burns
A quick look at recent improvements to WordPress development community.
To those of you who don't follow WordPress core development every day, some quick background.
Just a few years ago if you were looking to get involved in WordPress development there were a few places to go:
WordPress.org - Home of WordPress - download the code, development blog and documentation at codex.wordpress.org. Audience - users self-hosting WordPress. core.svn.wordpress.org -- Point your SVN client here to download the bleeding edge release. Audience - developers, savvy-end users. unit-tests.svn.wordpress.org -- Test framework and test cases lived in separate repository. core.trac.wordpress.org -- Bug tracking using the Python-based Trac tool IRC - A few different channels, but #wordpress-dev is where the core devs hang out and meetings take placeA surge of activity in the past few months in lowing the barrier to entry for budding core contributors.
Increased visibility through suite of P2-enabled sites.
Prettier, Better Organized and Less Intimidating to newcomers
Project philosophies, code standards, patch writing, and more in the Contributor Handbook.
New repository for core development
A blog post on August 6, 2013 kicked it off.
New home for the WordPress codebase.
Relegates WP to a subdirectory -- src Brings code from unit-tests.svn.wordpress.org in to the test/ directory Brings in internationalization tools in to build/
The new repository structure opens up many possiblities for root dotfiles.
grunt noun
Tools like this don't come from nowhere. Put Grunt in context.
gcc -c main.c command.c display.c utils.c gcc -o edit main.o command.o display.o utils.o
The idea of a "task runner" is not a new concept, nor is it exclusive to the web.
Compiled languages like C, Objective-C, etc. have been using them for years. In those environtments the idea of "building" code -- i.e. compiling source files into machine code and linking libraries -- is not optional. The simplest way to do this is to invoke the compiler (e.g. gcc), feeding it a list of files and configuration flags.
As you might imagine this approach does not scale, and developers quickly realized that building was for the birds.
Make was one of the first tools to solve this problem, and Grunt borrows a lot of concepts.
target ... : prerequisites ... recipe ... ...Source: gnu.org/software/make/
With Make developers created a "makefile", a set of instructions for how to build the project.
Developers could define "build targets" and their prerequistes and provide a "recipe" of build steps for each. Targets were not just confiend to building: - make test -- run unit tests - make clean -- clean build artificats - etc.
edit : main.o command.o display.o utils.o gcc -o edit main.o command.o display.o utils.o main.o : main.c defs.h gcc -c main.c command.o : command.c defs.h command.h gcc -c command.c display.o : display.c defs.h buffer.h gcc -c display.c utils.o : utils.c defs.h gcc -c utils.c clean : rm edit main.o command.o display.o utils.oSource: gnu.org/software/make/
$ make # Build the project $ make test # Run unit tests $ make install # Install resulting binary in your $PATH $ make clean # Clean up build artifacts
With a makefile in place the build process (and associated tasks) can be trigger with some simple commands.
A much easier way to build a project -- much less error prone, much easier to share among developers, and much easier to automate.
Grunt and tools like it were built to scratch an itch that many front-end developers started feeling a few years ago.
Increase in size and complexity of web projects Performance rennaisance brought on by the age of mobile Team environments and some of the complexities they introduce -- getting new developers started on a project, consistent development processes, etc.We built tools to make our lives easier
We got *really* cozy with our terminals. But...
$ sass --watch app/sass:public/stylesheets $ coffee -o lib/ -cw src/ $ uglifyjs --self -c -m -o /tmp/uglifyjs.js $ jshint --reporter=myreporter.js myfile.js
As the number of tools exploded, the need for a unified interface for project builds became apparent.
Grunt is a Javascript Task Runner built with Javascript, so you need a Javascript run time to use it. In this case V8 by way of Node.js.
NPM is the de facto package manager for Node.js, and is used to install Grunt itself as well as the plethora of community curated plugins.
Many of you probably have both of these installed already, but if not visit nodejs.org to get started.
$ brew install node
On the Mac I like Homebrew for node.js installation -- one command and you have both node and npm installed in an easily upgradeable package.
$ npm install -g grunt-cli
Once NPM is installed it's one command to install the Grunt CLI. This is a good one to install globally as you're likely to use it on several projects.
Both should be committed with your project.
$ grunt <task>[:<target>] # Examples $ grunt build # Run the `grunt build` task on all targets $ grunt build:scripts # Run the build task for "scripts" target only $ grunt # Run the default task (if confiugred)
There're two different workflows to discuss:
Setting up Grunt with a new project (or introducing it in to an existing one) Working on an existing project that has a Gruntfile in place# Fetch project from VCS, install development dependencies $ svn co http://develop.svn.wordpress.org/trunk $ npm install # Run tasks and prosper $ grunt --help # List tasks $ grunt [build] # Run default task (build) $ grunt uglify:core # Uglify scripts in the "core" group $ grunt jshint:themes # Lint scripts in the "theme" group with jshint $ grunt test # Run all PHPUnit and QUnit tests
# Fetch project from VCS, install development dependencies $ git clone git@github.com:bu-ist/bu-navigation # Initialize package.json $ npm init # Install Grunt and friends, saving dependencies in package.json $ npm install grunt --save-dev $ npm install grunt-contrib-uglify --save-dev $ npm install grunt-contrib-concat --save-dev $ npm install grunt-contrib-watch --save-dev # Edit Gruntfile... # Run tasks and prosper $ grunt $ grunt uglify $ grunt concat $ grunt watch
See the grunt-presentation branch of my fork of the navigation plugin.